Syntactic sugar (C#): Enum

Last week I had the opportunity to work with a rather expensive OCR SDK, one that could have been a great deal more elegant if the creators of the SDK used this sexy piece of syntactic chocolate, syntactic steak, syntac... uh I think you get the picture, observe the following extract.

public class OCRContext : IDisposable
	public OCRContext(int iLanguage)

There are two things I dislike about the constructor in the preceding snippet:
  1. Naming convention - iLanguage? Are you serious? This is what is called hungarian notation, the i describes the type of the variable, in this case its trying to tell us that language is an integer.

    Personally I feel that this convention doesn't have any place in a strongly typed language like C#.

  2. Use of a magic number - we need to pass an integer to the constructor, which tells the class which language to use, but what number represents English for example? Ideally we don't want someone to dig through a thousand page manual for something so trivial.

    This "magic number" convention can lead to all kinds of confusion, observe the if condition below:

    if ((iLanguage == 17) || (iLanguage == 2))
    	// Do some funky stuff

    Not all that clear from this snippet that 17 represents polish, while 2 is supposedly french...

But wait, it gets a little bit more interesting, the developer included the following crude class:

public class Languages
	public const int Afrikaans = 33;
	public const int English = 0;

This is somewhat helpful, but it would have been nicer if we had a programmatic relation enforcing this class (telling us where we can find our languages), providing some kind of constraint at the same time.

No enumerator
Like you can see from preceding image, we still need to pass an int value, nothing is preventing or telling us to do something else.

This is where our syntactic sugar in question comes into play, we can group our constants into a neat strongly typed little box of values, which constrains us to what we can send to the parameter and leads the developer to the list of possible constants.

public class OCRContext : IDisposable
	public OCRContext(Languages language) 
	// something
	// etc..
// Poorly designed enum don't do this, read on..
public enum Languages


Obviously (like with everything else), we can misuse this piece of sugar ending up with a system suffering from hyperglycemia.

Seeing as the underlying type of our enum is an int (can also use other integral types) it can lead to some interesting issues when using an enum as bit flags via bitwise operators.

Have a look at the following snippet (using the Languages enum in this post):

Languages languages = Languages.Afrikaans | Languages.English;
if (languages == Languages.Afrikaans)
if (languages == Languages.English)
if (languages == (Languages.Afrikaans | Languages.English))

(Note: When an enumeration is to be used in bitwise operations, be sure to set the flags attribute)

Which produces the following:

Broken Enumeration

What happend here exactly? Why did the first condition validate as true?

Well, its rather simple, if we don't provide enums with values, each member will simply be incremented starting by 0, so the value behind Languages.English is 0 - which technically means we didn't really add English to the equation.

To solve this issue you can add values to your members like seen below.

public enum Languages
	English = 1,
	Afrikaans = 2

Or according to best practices rather provide a sensible default value.

public enum Languages

There are a few other valuable design guidelines provided by microsoft (not going to go into too much detail in this post) with regards to enumeration, which you can read more about over here.

There is one last tip I want to give you before I send you on your way.

Lets assume that you did infact design your class like the one seen at the beginning of this post and you want to use an enum instead, but unfortunately you've got a billion people using your class already, you can simply use the obsolete attribute like seen in the following snippet.

class OCRContext
    [Obsolete("Rather use OCRContext(Languages language)")]
    public OCRContext(int iLanguage)
        // some code
    public OCRContext(Languages language)
        // some code

If the developer tries to use the old constructor, he will get the following warning in his IDE (assuming he's using Visual Studio):


Additional reading

Enumeration Design
Enumeration Types (C# Programming Guide)
When to Use an Enumeration


RE: Constructor Chaining

Unchain my constructor, baby let me be.... hehehe. Assuming of course that the old constructor supports the whole idea of flags (or not), I guess its upto the scenario. But yes, I definitely agree.


I agree, there's not much that's more frustrating when people writing APIs don't use enums. Though it's not the point of the article, in the spirit of writing maintainable code the second constructor probably shouldn't have a body and should be: public OCRContext(Languages language) : this((int)language) instead.

Post comment

Name *
Body *
Security Code
* Required fields

Latest Posts

MS SQL: Parameter Sniffing

2012-05-21 22:38:48

Be the best stalker you can be

2011-12-13 22:33:54

Top 5 posts

Moving items between listboxes in example

Move items between two listboxes in, VB.NET) and PHP
2008-06-12 17:07:43

Simple WYSIWYG Editor

Creating a WYSIWYG textbox for your website is actually quite simple.
2007-02-01 12:00:00

C# YouTube : Google API

Post on how to integrate with YouTube using the Google Data API
2011-03-12 08:37:51

Populate a TreeView Control C#

Populate a TreeView control in a windows application.
2009-08-27 16:01:03

Cross Browser Issues: Firefox Word Wrapping

Firefox word wrapping issues
2008-06-09 09:51:21