CODEWITHSUNDEEP
c#types
SMR
SMR

Reputation:

Using enum to represent IDs in C#

I was using plain ints to represent some IDs internally but I needed a constant to represent a null ID, while I was playing around I realised that this would work:

public enum ID : int { Null = -1 }

then for example:

ID myID = ID.Null;

Is this a bad idea?
Is it worse that just using plain ints?
If it is a problem, what is the best way to represent IDs?

Thanks.

Upvotes: 1

Views: 733

Answers (5)

SMR
SMR

Reputation:

Thanks for the answers. I guess what I like about this is firstly it makes my code a bit easier to read than using a plain int or a int? without the unnecessary overhead of a separate ID class, e.g.:

int? myId = getAnIDFromSomewhere();

vs:

ID myId = getAnIDFromSomewhere();

Secondly it ties the type and the Null constant together into one package (which int? also does of course). On the other hand it feels wrong somehow hence my question here.

One thing that led me to this was that I couldn't include a NullID constant on the interface that returns/uses the IDs (since C# won't let me), which felt wrong too (since the possibility of returning NullID seems like part of that interface).

Anyway I think the responses here make it clear that if I carry on with my crazy enum scheme I'm going to end up featured on thedailywtf.com so I'm abandoning this idea. :)

Thanks again.

Upvotes: 0

Hoghweed
Hoghweed

Reputation: 1948

I think depends, but I like more working with enunmerations (in many of the cases) that working on simple constants. This beacuse enums represent something more detailed than a constant, and you can use enums in many cases and many usages.

I think too that you're not representing a "language null" but a "conventional null" in fact you're setting your ID as enum value of value -1, so this speaks well what you intend to do and what I'm talking about, for that reason, if you'll going to use "language null" it's still a good idea to use a nullable Nullable<int> or int?.

In some cases when working for example with ORM's or similar, it's a good practice to define a kind of un-set-value instead of a null value, so could be useful to use an enumeration, as I said before it depends.

At last I think, think better what kind of null you need to represent

Upvotes: 0

Benjol
Benjol

Reputation: 66617

You only need one value, Null? If so I'd use a const.

Depends on scope also - if you are using this enum inside a class, across several classes, or from one assembly to another. If you are using enums cross-assembly, you need to watch out for a weird case (for which I can't currently find any reference and can't remember the exact details) whereby enum names and values can appear to be unsynchronised - though I think you can avoid this by explicitly defining the values, as you have done here.

Upvotes: 0

Paul Suart
Paul Suart

Reputation: 6713

Why not just use a constant, as you state in the question? If you want to have a range of "magic" Ids, I suppose using an enum is as good a method as any.

As the other poster suggests, using one of the built-in constants such as int.MinValue is almost certainly the best option.

Upvotes: 2

Gideon
Gideon

Reputation: 18501

Why don't you use a Nullable int ? Nullable<int> or int?.

EDIT
Or if you don't like the that, use the build-in int.MinValue as your constant for representing null id. Either way, they are standard, and not some custom hack.

Upvotes: 7

Related Questions