I’ve reviewed a lot of Java code where enums were treated like magic constants that “just work,” and the ordinal value quietly shaped behavior behind the scenes. That quiet behavior is exactly why I want you to understand ordinal() clearly. When you know how it’s assigned, what it means, and what it doesn’t mean, you can design enums that stay stable as your code grows. I’ll show you a clean, runnable example that prints ordinal values, then I’ll contrast that with enums that carry their own explicit data. Along the way, I’ll call out common mistakes I see in production, the right times to use ordinal(), and the cases where it can introduce subtle bugs. I’ll also share a few patterns I recommend in modern Java projects, including quick tests and simple safety checks that fit 2026 workflows. If you’ve ever wondered why an enum’s order matters, or how to show the ordinal without confusing it for a real ID, you’re in the right place.
Enum ordinals: the hidden index you already use
Enums in Java are fixed sets of constants, and each constant gets an ordinal value. That ordinal is simply its position in the enum declaration, starting from zero. The first constant you declare has ordinal 0, the next one gets 1, and so on. The ordinal value isn’t something you set directly; it is a structural fact of the declaration order. Think of it like a row number in a spreadsheet: you can read it, but you shouldn’t treat it as a business key.
I often explain it to teammates with a simple analogy: imagine a list of coffee sizes on a menu board. The position of each size tells you its ordinal. If the board gets rearranged, the positions shift, even if the actual sizes and prices don’t change. The ordinal is great for quick internal indexing or ordering in a limited scope, but it’s a poor choice for stable identifiers. If you want a stable identifier, you should define an explicit field and store it as data in the enum constant itself.
The key takeaway: ordinal() returns a small integer that reflects declaration order only. It does not represent a domain ID, and it does not track the value you may store inside the enum. That’s why I always treat ordinal as a convenience for internal logic, not for persistent storage or external contracts.
Why ordinal() exists and why it’s final
The ordinal() method comes from java.lang.Enum. Its signature is:
public final int ordinal();
There are two details that matter for everyday Java work:
1) It’s final, so you cannot override it. Every enum constant gets ordinal behavior defined by the Java runtime.
2) It’s an instance method, not static. That means you call it on a specific enum constant, not on the enum type itself.
Because ordinal() is final and derived from declaration order, you can treat it as a reliable way to map enum constants into arrays or to produce a stable display order within a short-lived process. But “reliable” here is scoped to a given version of the code. The moment someone reorders the constants or inserts a new constant in the middle, every ordinal after that point shifts. That’s why I discourage using ordinal in serialization or database storage. You can, but I want you to do it with eyes open and a clear migration plan.
One more detail I find people miss: you can’t “set” ordinal. You can only read it. Even if you attach custom fields or constructors to an enum, ordinal is still computed from position in the declaration.
A clean, runnable example that prints ordinal values
Here’s a complete Java example that prints each enum constant along with its ordinal. It’s small, but it helps you see the rule clearly in a running program.
// Java program that prints ordinal values for each enum constant
enum Student {
Rohit,
Geeks,
Author
}
public class OrdinalDemo {
public static void main(String[] args) {
System.out.println("Student Name:");
for (Student s : Student.values()) {
System.out.print(s + " : " + s.ordinal() + " ");
}
System.out.println();
}
}
Expected output:
Student Name:
Rohit : 0 Geeks : 1 Author : 2
Notice what is and isn’t happening:
- The ordinal values are zero-based.
- The names are in the same order as the enum declaration.
- There’s no extra logic; the ordinal is computed by the runtime based on position.
If you reorder the enum constants, the ordinal output changes. This alone is a strong reminder that ordinal values are not domain data; they’re position metadata. I use ordinal in small, local contexts where I can guarantee the enum order won’t change without deliberate review.
Custom values vs ordinal: two separate axes
Now let’s extend that example. I’ll assign a custom ID to each enum constant while still showing its ordinal. This shows that the ordinal is unaffected by your custom fields.
// Java program that shows ordinal and custom IDs for enum constants
enum StudentId {
james(3413),
peter(34),
sam(4235);
private final int id;
StudentId(int id) {
this.id = id;
}
public int getId() {
return id;
}
}
public class OrdinalWithIdsDemo {
public static void main(String[] args) {
System.out.println("Student Id List:");
for (StudentId s : StudentId.values()) {
System.out.print(s + " : " + s.ordinal() + " ");
}
System.out.println();
System.out.println("---------------------------");
for (StudentId s : StudentId.values()) {
System.out.println("student Name : " + s + ": " + s.getId());
}
}
}
Expected output:
Student Id List:
james : 0 peter : 1 sam : 2
---------------------------
student Name : james: 3413
student Name : peter: 34
student Name : sam: 4235
The key insight is that the ordinal values remain 0, 1, and 2, even though the IDs are 3413, 34, and 4235. If you reorder the enum constants, the IDs stay the same, but the ordinals change. That means the custom ID is stable, while ordinal is not.
When should you choose each?
- Use the custom ID when you need a stable mapping to a database key, a file format, or a network protocol.
- Use ordinal when you need a compact index inside a fixed, local algorithm where the enum order is meaningful.
If you store ordinal in a database and then later insert a new enum constant in the middle, every stored value becomes incorrect without a migration. I’ve seen that in real systems, and it’s a painful, preventable bug.
Traditional vs modern enum patterns in 2026
If you’re building new code today, you can be more intentional about enum design. Here’s a quick comparison of two approaches I commonly see and what I recommend now.
Traditional pattern
—
Use ordinal() as the ID
Persist ordinal in DB
Use name() for UI
Rely on declaration order
Reordering breaks data
What makes the modern pattern safer is that it decouples domain meaning from declaration order. You can still use ordinal for quick indexing in short-lived logic, but your external data stays stable when the enum evolves.
I’m also seeing more teams in 2026 use “safety adapters” around enums: a small static lookup method that maps a stable code to an enum constant and handles unknown values gracefully. That pattern helps when data flows across services or when you have to support backward compatibility.
When ordinal() is a good fit, and when it’s a trap
I’ll be direct here. There are a few clear cases where ordinal() is safe and useful, and a few where it will cause real bugs.
Good fits:
- Small, local indexing: using ordinal() to index a short array in a single class where the enum order is part of the algorithm.
- Debug output or logging: showing ordinal to help confirm order during development.
- Simple sorting where declaration order is intentional and fixed.
Traps to avoid:
- Persisting ordinal in a database or file. If the enum order changes, stored values break.
- Sending ordinal across the network as a protocol field. It ties clients to a specific enum order.
- Using ordinal as a “priority” when the priority can change. That’s a smell; use an explicit field instead.
I recommend a clear rule of thumb: if the value outlives the running JVM or needs to be stable across versions, don’t use ordinal. Store an explicit value.
Common mistakes I see
- Reordering enum constants “for readability” and unintentionally changing ordinals.
- Inserting a new constant in the middle and forgetting about stored ordinals.
- Confusing ordinal with a custom ID and comparing the wrong values in logic.
If you already have code that persists ordinal, you can still move away from it. Add an explicit field, write a migration, and keep a small compatibility layer that translates old ordinal values to the new explicit values. It’s extra work, but it avoids a long tail of data bugs.
A practical pattern: explicit codes with a safe lookup
Here’s a pattern I recommend in real projects. It gives you a stable code and a lookup method that returns a fallback for unknown inputs.
import java.util.HashMap;
import java.util.Map;
enum PaymentStatus {
PENDING("P"),
AUTHORIZED("A"),
SETTLED("S"),
FAILED("F");
private final String code;
PaymentStatus(String code) {
this.code = code;
}
public String getCode() {
return code;
}
private static final Map BY_CODE = new HashMap();
static {
for (PaymentStatus s : values()) {
BY_CODE.put(s.code, s);
}
}
public static PaymentStatus fromCode(String code) {
PaymentStatus status = BY_CODE.get(code);
return status != null ? status : FAILED; // safe fallback
}
}
Ordinal still exists and still works here, but it’s not part of the public contract. You can reorder these constants if you ever need to, and the code mappings remain stable. This is the pattern I advise whenever the enum is part of storage or a network interface.
Performance and edge cases
The ordinal() method is trivial: it returns an internal integer. In a typical JVM, it’s effectively constant time and extremely fast, typically in the tens of nanoseconds to low microseconds for a single call, depending on your runtime and JIT state. You won’t see ordinal() show up in real performance profiles unless you call it millions of times in a tight loop. Even then, the performance cost is dominated by whatever you do next with the value.
The real performance risk is not runtime; it’s maintenance. If you use ordinal in data storage, the cost of migration and bug fixes will dwarf any micro-level runtime benefit.
Edge cases to keep in mind:
- Enum reordering: changes ordinal values for all following constants.
- Enum insertion: shifts ordinals for subsequent constants.
- Serialization with default Java serialization: ordinal isn’t the storage key, but name is; changing enum constants can still break compatibility if a constant is removed or renamed.
When I evaluate edge cases, I ask: “Will this value need to survive code changes?” If yes, I avoid ordinal and use explicit fields. If no, ordinal is often fine.
Quick tests you can add without much overhead
I like small tests that lock in expected enum behavior. This is especially useful when enums are part of core logic. Here’s a tiny JUnit 5 test that checks both ordinal and a custom code. It serves as a warning signal if someone changes the enum order or data.
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;
class PaymentStatusTest {
@Test
void ordinalAndCodeAreAsExpected() {
assertEquals(0, PaymentStatus.PENDING.ordinal());
assertEquals("P", PaymentStatus.PENDING.getCode());
assertEquals(3, PaymentStatus.FAILED.ordinal());
assertEquals("F", PaymentStatus.FAILED.getCode());
}
}
I don’t rely only on ordinal assertions in long-lived systems, but the test does something valuable: it forces the team to think about the impact of enum changes. If a change breaks the test, you can decide whether the change is safe or whether you need a migration. That’s a healthy friction point in most teams.
In 2026, many teams also run AI-assisted reviews that flag risky enum changes. I’ve seen those tools highlight “enum reordering with stored ordinals” as a top-tier warning. Even if your tooling is lighter, you can build the same protection by keeping a simple test like the one above.
When you should still use ordinal()
Despite the warnings, I still use ordinal in specific cases. Here are examples where I think it’s the right tool:
- Array-based lookup for small, fixed enums. Example: mapping enum to a short, static configuration table where the order is a deliberate part of the design.
- Compact indexing in performance-sensitive code where you fully control the enum and its evolution.
- Debugging output where ordinal helps confirm order or branch selection.
Here’s a small example where ordinal makes sense: mapping weekdays to an array of daily capacity values. The order is stable, and the array is only used in a small internal context.
enum Weekday {
MON, TUE, WED, THU, FRI, SAT, SUN
}
public class CapacityByDay {
private static final int[] CAPACITY = { 50, 60, 70, 80, 90, 40, 30 };
public static int capacityFor(Weekday day) {
return CAPACITY[day.ordinal()];
}
}
If the enum order is treated as part of the algorithm’s contract and is not going to change casually, this is a clean and readable solution.
Deepening the mental model: what ordinal is and is not
I like to separate “enum identity” into three layers. This mental model helps me decide whether ordinal is appropriate.
1) Name layer: The string name of the constant (for example, PENDING). This is usually stable unless you rename.
2) Ordinal layer: The declaration position (0, 1, 2, …). This changes if you reorder or insert.
3) Domain layer: The explicit data you define (like a code, ID, priority, or display label). This is fully controlled by you.
Ordinal lives in layer 2, so I only use it when I’m deliberately relying on order. The moment I need the domain layer to be stable, I add explicit fields. This simple model prevents a surprising number of bugs, especially in larger codebases where enums are used in multiple modules.
A larger example: enum with explicit code, label, and priority
Here’s a more production-style enum that includes a stable code, a label for UI, and a priority for ordering. Notice how each concern has its own field, and ordinal is just a convenience if I want it.
import java.util.Arrays;
import java.util.Map;
import java.util.function.Function;
import java.util.stream.Collectors;
enum TicketSeverity {
LOW("L", "Low severity", 3),
MEDIUM("M", "Medium severity", 2),
HIGH("H", "High severity", 1),
CRITICAL("C", "Critical severity", 0);
private final String code;
private final String label;
private final int priority;
TicketSeverity(String code, String label, int priority) {
this.code = code;
this.label = label;
this.priority = priority;
}
public String getCode() { return code; }
public String getLabel() { return label; }
public int getPriority() { return priority; }
private static final Map BY_CODE =
Arrays.stream(values()).collect(Collectors.toMap(TicketSeverity::getCode, Function.identity()));
public static TicketSeverity fromCode(String code) {
TicketSeverity severity = BY_CODE.get(code);
return severity != null ? severity : LOW;
}
}
This enum gives me a stable code for storage, a label for display, and a priority for ordering. If I need to sort severities, I can use the explicit priority. If I need to index quickly in some internal array, ordinal is still there, but it’s not my public contract.
Enum ordering vs business ordering
One of the biggest sources of confusion is when declaration order is treated as a business order. I’ve seen enums like this in real systems:
enum ShippingSpeed {
ECONOMY,
STANDARD,
EXPRESS,
OVERNIGHT
}
In this case, the declaration order is a kind of business order (from slow to fast). But what happens when the business adds “SAME_DAY” and wants it between EXPRESS and OVERNIGHT? If you insert it in the middle, ordinals shift, and any stored ordinals break. If you add it at the end, your business order is now wrong. That’s why I often separate the two:
enum ShippingSpeed {
ECONOMY("E", 4),
STANDARD("S", 3),
EXPRESS("X", 2),
SAME_DAY("D", 1),
OVERNIGHT("O", 0);
private final String code;
private final int businessOrder;
ShippingSpeed(String code, int businessOrder) {
this.code = code;
this.businessOrder = businessOrder;
}
public String getCode() { return code; }
public int getBusinessOrder() { return businessOrder; }
}
Now I can sort by businessOrder without tying myself to declaration order. If someone reorders the enum for readability, the business order stays stable.
Using EnumSet and EnumMap safely with ordinal()
Java’s EnumSet and EnumMap are optimized with ordinals under the hood. That’s a positive use of ordinal: the JDK uses ordinals internally to provide fast, memory-efficient collections tailored to enums. The key point is that you don’t have to care about ordinals when you use these collections; the API handles it safely.
Example:
import java.util.EnumMap;
import java.util.EnumSet;
enum FeatureFlag {
SEARCH, RECOMMENDATIONS, EXPORT, AI_SUMMARY
}
public class FeatureConfig {
public static void main(String[] args) {
EnumSet enabled = EnumSet.of(FeatureFlag.SEARCH, FeatureFlag.EXPORT);
EnumMap limits = new EnumMap(FeatureFlag.class);
limits.put(FeatureFlag.SEARCH, 1000);
limits.put(FeatureFlag.EXPORT, 50);
System.out.println("Enabled: " + enabled);
System.out.println("Search limit: " + limits.get(FeatureFlag.SEARCH));
}
}
This code benefits from ordinal-based performance without exposing ordinal as part of your domain. That’s an ideal outcome: internal ordinal usage is fine as long as your external contract doesn’t depend on it.
Serialization: what’s safe and what’s risky
Default Java serialization uses the enum’s name, not ordinal. That’s a good thing: name is more stable than ordinal in most codebases. Still, serialization has pitfalls:
- If you rename or remove an enum constant, deserialization will fail.
- If you reorder constants, serialization is unaffected.
- If you persist ordinals manually (for example, as a byte), you are now responsible for migrations.
I usually avoid Java’s native serialization for data exchange and instead rely on explicit encoding. If I’m using JSON, I’ll serialize the explicit code or name. In modern apps, I often add a safe parsing method that handles unknown values.
For JSON with a custom code, I’ll do something like:
enum PaymentStatus {
PENDING("P"), AUTHORIZED("A"), SETTLED("S"), FAILED("F");
private final String code;
PaymentStatus(String code) { this.code = code; }
public String getCode() { return code; }
public static PaymentStatus fromCode(String code) {
for (PaymentStatus s : values()) {
if (s.code.equals(code)) return s;
}
return FAILED;
}
}
Then I configure my JSON layer to use getCode() for serialization and fromCode() for deserialization. The key benefit is that I am explicit about stability, and I never leak ordinal into the wire format.
Database mapping: a practical migration path away from ordinal
If you already have ordinals stored in a database, you can migrate to explicit codes safely. Here’s a clear, practical sequence I’ve used:
1) Add a new column for the explicit code (for example, paymentstatuscode).
2) Update your enum to include explicit codes and a lookup method.
3) Backfill existing rows using the current ordinal-to-code mapping.
4) Switch the application to read from the explicit code column.
5) Keep a temporary compatibility layer for legacy rows.
6) Remove the old ordinal column once you confirm consistency.
A short migration snippet can look like this (pseudocode for clarity):
// Old: status_ordinal (int)
// New: status_code (string)
String code = PaymentStatus.values()[statusOrdinal].getCode();
updateRow(id, code);
This migration only works if your ordinal mapping is still in the same order as when the data was written. That’s why I do these migrations as soon as I notice ordinal persistence. The longer you wait, the harder it becomes to guarantee accuracy.
A deeper example: enum-backed configuration tables
Sometimes I want ordinal for compact indexing, but I also need explicit data. In those cases, I use both in a controlled way.
enum PlanTier {
FREE("FREE", 0),
PRO("PRO", 1),
ENTERPRISE("ENT", 2);
private final String code;
private final int featureIndex;
PlanTier(String code, int featureIndex) {
this.code = code;
this.featureIndex = featureIndex;
}
public String getCode() { return code; }
public int getFeatureIndex() { return featureIndex; }
}
public class PlanFeatures {
private static final boolean[][] FEATURES = {
// FREE, PRO, ENTERPRISE
{ true, false, false }, // feature A
{ false, true, true }, // feature B
{ false, true, true } // feature C
};
public static boolean hasFeature(PlanTier tier, int featureId) {
return FEATURES[featureId][tier.getFeatureIndex()];
}
}
Here I explicitly store a featureIndex so I don’t depend on ordinal. If I later reorder PlanTier, my features stay correct. I still have ordinal available, but I’m not using it for critical indexing. This is a small change that saves a lot of future confusion.
Performance considerations in real systems
I mentioned earlier that ordinal() is extremely fast. Let me make that practical:
- For most workloads, calling ordinal() is “free” in the sense that it doesn’t change your performance profile.
- The bottlenecks usually live elsewhere: network calls, database queries, JSON parsing, or disk IO.
- The only time ordinal() matters is when you build algorithms that use arrays and ordinals heavily. Even then, the use of ordinal is not the slow part; the array access and the algorithm itself matter more.
In other words, avoid using ordinal for performance “because it’s fast.” It’s fast, yes, but it’s also fragile. I always weigh the stability cost against the small runtime gain.
Common pitfalls in production (and how I avoid them)
Here’s a short list of issues I’ve seen repeatedly, along with the habits I use to prevent them.
Pitfall: Reordering enum constants for readability.
Avoidance: Add a comment like “Order is part of logic” or a test that locks the order in place.
Pitfall: Using ordinal in a switch for business decisions.
Avoidance: Use explicit fields or add behavior methods directly on enum constants.
Pitfall: Comparing ordinals across different enums.
Avoidance: Never compare ordinals from different types; it’s meaningless and error-prone.
Pitfall: Storing ordinal in a cache that outlives the process.
Avoidance: Store explicit code or name instead.
Pitfall: Adding a new enum constant in the middle without a migration.
Avoidance: Add new constants at the end or migrate stored values in one controlled change.
Behavior-rich enums: avoiding ordinal entirely
Enums are great for attaching behavior. If you define methods on each constant, you can avoid ordinal for many business cases.
enum DiscountPolicy {
NONE {
@Override public double apply(double price) { return price; }
},
TEN_PERCENT {
@Override public double apply(double price) { return price * 0.90; }
},
VIP {
@Override public double apply(double price) { return price * 0.85; }
};
public abstract double apply(double price);
}
Here, behavior is the “real” data. I don’t need ordinal to determine the discount. This pattern is safer than a switch that relies on ordinal or position.
Making ordinal usage explicit with documentation
When I do choose ordinal, I make that decision obvious. A short comment can go a long way.
// Order matters: index aligns with CAPACITY by ordinal.
private static final int[] CAPACITY = { 50, 60, 70, 80, 90, 40, 30 };
This isn’t about being verbose; it’s about making the dependency explicit for future readers. In long-lived projects, this kind of clarity prevents accidental bugs.
Handling unknown values safely
When enums are used at system boundaries, I always include a safe fallback. This is particularly important when services evolve at different speeds.
enum DeviceType {
MOBILE("M"), DESKTOP("D"), TABLET("T"), UNKNOWN("?");
private final String code;
DeviceType(String code) { this.code = code; }
public static DeviceType fromCode(String code) {
for (DeviceType t : values()) {
if (t.code.equals(code)) return t;
}
return UNKNOWN;
}
}
With this pattern, a new device code won’t crash my app. It gracefully degrades, and I can log a warning for analysis.
Practical scenario: feature flags and rollout ordering
Enums often show up in feature flag systems. Developers sometimes use ordinal to define rollout ordering. I prefer an explicit field so rollout changes don’t break history.
enum RolloutPhase {
ALPHA("A", 1),
BETA("B", 2),
GA("G", 3);
private final String code;
private final int phaseOrder;
RolloutPhase(String code, int phaseOrder) {
this.code = code;
this.phaseOrder = phaseOrder;
}
public int getPhaseOrder() { return phaseOrder; }
}
If I later insert an “EARLY_ACCESS” phase, I can set phaseOrder without breaking existing records. That’s much safer than relying on ordinal.
Using ordinal in arrays: a safe template
If you want to use ordinal, here’s the template I keep in mind:
1) The enum order is part of the algorithm’s design.
2) The mapping is local to one class or method.
3) The data does not persist beyond the current version.
4) There’s a test or comment that locks in the assumption.
When those conditions are met, ordinal is acceptable and often convenient.
A small checklist before you use ordinal()
I ask myself these questions before using ordinal:
- Will this value be stored or transmitted?
- Will the enum likely change as the product evolves?
- Does the order carry real domain meaning or is it incidental?
- Can a future developer reorder the enum without understanding the consequence?
If any answer points to risk, I switch to explicit fields. It’s a low-effort change with big long-term payoff.
A note on AI-assisted workflows in 2026
In recent projects, I’ve seen AI review tools flag enum changes. The most common warning is: “Enum ordering changed; check for ordinal persistence.” I like that because it nudges the team to think about versioning and stored values. Even without AI tools, you can create a similar guardrail by adding tests or simple pre-commit checks that scan for ordinal persistence patterns in serialization or database code.
Completing the earlier example with a useful test strategy
Earlier I started a section about tests and it trailed off. Here’s the full approach I like:
1) One test that verifies critical ordinals where ordinal is part of logic.
2) One test that verifies explicit codes, because those should be stable.
3) Optional tests that validate the lookup method and unknown inputs.
Here’s a compact example of all three:
import static org.junit.jupiter.api.Assertions.*;
import org.junit.jupiter.api.Test;
class TicketSeverityTest {
@Test
void ordinalIsStableForInternalIndexing() {
assertEquals(0, TicketSeverity.CRITICAL.ordinal());
}
@Test
void codeIsStableForPersistence() {
assertEquals("C", TicketSeverity.CRITICAL.getCode());
assertEquals("L", TicketSeverity.LOW.getCode());
}
@Test
void fromCodeHandlesUnknowns() {
assertEquals(TicketSeverity.LOW, TicketSeverity.fromCode("?"));
}
}
This combination gives you a quick safety net without being too noisy. If someone changes the enum, the test failures force a deliberate discussion.
A quick comparison: ordinal vs name vs explicit code
Sometimes developers ask me, “Why not just use name() instead of adding a code?” That’s a fair question. Here’s how I think about it:
- name(): stable if you never rename. Simple and readable. But renaming is common in long-lived projects, and name() couples you to a code-level identifier.
- ordinal(): stable only if you never reorder. High risk if you insert or reorder.
- explicit code: stable if you treat it as a domain contract. Extra work, but best for storage and integration.
If I expect any renaming, I prefer explicit code. It’s a small cost that protects me from future refactors.
Wrapping up the central idea
I want you to walk away with a simple mental model: ordinal() is a positional index, not a business identifier. It’s computed from enum declaration order, it’s final, and it starts at zero. That makes it safe for short-lived indexing and ordering in code you control, but fragile for anything stored or shared beyond the JVM. The moment you need stability across versions, you should attach an explicit code or ID to each enum constant and use that instead.
If you’re working in a codebase right now, pick one enum that is stored in a database or sent across a network. Check whether it uses ordinal. If it does, add an explicit code field, introduce a safe lookup method, and plan a migration. The effort is usually small and the risk reduction is huge.
If you only need ordinal for a local mapping, keep it local and make the dependency obvious. I like to add a short comment near the array that says the order is intentional. It reminds future readers that the ordinal is doing real work.
Finally, add a tiny test for any enum that matters. A single test that asserts critical ordinals and codes is a great guardrail. It creates a deliberate pause when someone changes the enum, and that pause is often where real bugs are prevented.
What to do next (practical steps)
Here’s a short, actionable plan you can apply today:
1) Scan your codebase for uses of ordinal() in persistence or serialization.
2) For each risk area, add explicit codes and a lookup method.
3) Add one or two tests that lock in expected codes and ordinals.
4) Add a small comment in places where ordinal-based ordering is intentional.
5) Document any enum that is part of a public contract.
If you take just these steps, you’ll eliminate most of the subtle enum bugs I see in production. And if you keep the mental model clear—ordinal is an index, not an ID—you’ll be able to use ordinal confidently when it’s actually the right tool.
