Take the 2-minute tour ×

Are there compelling reasons to use a Flags enum (i.e., a bitmask) over a HashSet of regular enums? As far as I can tell, both solve the same problem:

enum Color { Red, Green, Blue }

enum Colors { None = 0, Red = 1, Green = 2, Blue = 4 }

void Test()
    // initialization
    var supportedColors1 = new HashSet<Color> { Color.Red, Color.Green };
    var supportedColors2 = Colors.Red | Colors.Green;

    // comparison
    if (supportedColors1.Contains(Color.Green)) { /* ... */ }
    if ((supportedColors2 & Colors.Green) != 0) { /* ... */ }

    // manipulation
    supportedColors2 ^= Colors.Red;  // if I'm sure that Red is contained
    supportedColors2 &= ~Colors.Red; // if I'm not sure

It might be a matter of taste, but for someone without a hardware or system-level bit-flipping background (= my co-workers), I would think that the Set option is more readable. I can see the advantage of the Flags option when micro-optimization is required (better performance, less memory) or when P/Invoking the Windows API, but for standard line-of-business database applications I'm tempted to choose the Set option for readability.

Are there some advantages of the Flags option that I have missed and that justify its use in "regular" code?

share|improve this question
add comment

3 Answers

up vote 4 down vote accepted

Are there some advantages of the Flags option that I have missed

Besides the fact that they are orders of magnitude more efficient? This may not be relevant for you but it’s such an obvious optimisation that it often makes sense.

Furthermore, if you don’t like the bit operation syntax (and I don’t blame you), try defining extension methods to encapsulate them. But I would argue that any competent programmer, no matter their background, absolutely need to know common bit operations anyway. If your coworkers are stumped by this usage, you’ve got big problems.

share|improve this answer
I guess I should step in and defend my coworkers here: They are great developers, but they have developed LOB applications in VBA and .NET for years without needing bit operations, so understanding a &= ~b definitely takes a bit longer than a.Remove(b). –  Heinzi Jan 31 '12 at 10:18
@Heinzi Unfortunately I don’t think this is defensible. It’s just an essential skill, like using a knife as a cook, even if you have a blender. –  Konrad Rudolph Jan 31 '12 at 10:25
add comment

The HashSet solution maybe works fine except efficiency issues. But I think a developer should write correct codes as better as he could, instead of as acceptable(by other coworkers) as he could...If someone is not well skilled enough to understand your clear and correct solution, you needn't pay for that.

share|improve this answer
add comment

as you know you can achieve the same with both of them. Using the HashSet will probably be a better choice if you want to store data coming from a database, there will not be any noticeable difference in terms of performances. For sure you will end up with a much more usable (and readable) code and with a type that "fits" better with the data you want to sort out. In both the cases you will iterate or check if a value is present in your container. While the Hashset comes with all the extensions typical for a list (contains, etc..) with the flags you will have to implement these functionalities by yourself (with custom extension methods for instance). The result will be a slowdown in development and less readable code (for your colleagues :) without any type of improvement. Here's a good overview about Enum flags

share|improve this answer
I don’t think your comment about database storage is correct. Can you elaborate? The rest is also tenuous. Implementing the extension methods is trivial and fast and you only need to do it once. There will be no “less readable code” after that – it will be identical to using a HashSet. –  Konrad Rudolph Jan 31 '12 at 10:26
Hi, yes the question is about a database driven application, so assuming we are getting a dataset from a db and we need to store it somewhere in order to then sort it/filter it I think the quickest (and common practice) solution would be to use a generic collection of some type. The result is the same, the performances will be the same (the hashset performs well) and you will not have the hassle of implementing by yourself all the extensions methods supported by the Hashset. –  Giorgio Minardi Jan 31 '12 at 10:53
For sure it's faster to reuse something already implemented than rewrite it yourself if there's no evident benefits from doing it. Another point is the familiarity of most of the developers (if you work in a team) with lists and their methods rather than Enum flags. –  Giorgio Minardi Jan 31 '12 at 10:53
add comment

Your Answer


