Question

I started working on a large c# code base and found the use of a static class with several const ints fields. This class is acting exactly like an enum would.

I would like to convert the class to an actual enum, but the powers that be said no. The main reason I would like to convert it is so that I could have the enum as the data type instead of int. This would help a lot with readability.

Is there any reason to not use enums and to use const ints instead?
This is currently how the code is:

public int FieldA { get; set; }
public int FieldB { get; set; }

public static class Ids
{
    public const int ItemA = 1;
    public const int ItemB = 2;
    public const int ItemC = 3;
    public const int ItemD = 4;
    public const int ItemE = 5;
    public const int ItemF = 6;
}

However, I think it should be the following instead:

public Ids FieldA { get; set; }
public Ids FieldB { get; set; }

Answer 1

I think many of the answers here ignore the implications of the semantics of enums.

• You should consider using an enum when the entire set of all valid values (Ids) is known in advance, and is small enough to be declared in program code.

• You should consider using an int when the set of known values is a subset of all the possible values – and the code only needs to be aware of this subset.

With regards to refactoring – when time and business contraints allow, it’s a good idea to clean code up when the new design/implementation has clear benefit over the previous implementation and where the risk is well understood. In situations where the benefit is low or the risk is high (or both) it may be better to take the position of “do no harm” rather than “continuously improve”. Only you are in a position to judge which case applies to your situation.

By the way, a case where neither enums or constant ints are necessarily a good idea is when the IDs represent the identifiers of records in an external store (like a database). It’s often risky to hardcode such IDs in the program logic, as these values may actually be different in different environments (eg. Test, Dev, Production, etc). In such cases, loading the values at runtime may be a more appropriate solution.