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
{
	English,
	Afrikaans
}
 

Enumerator

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)
    Console.WriteLine("Afrikaans");
 
 
if (languages == Languages.English)
    Console.WriteLine("English");
 
 
if (languages == (Languages.Afrikaans | Languages.English))
    Console.WriteLine("AfrikaansEnglish");
 

(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
{
	None,
	English,
	Afrikaans
}
 


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):

Obsolete

Additional reading

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








Comments



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.


Feedback

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 *
Email
Title
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 ASP.net/PHP example


Move items between two listboxes in ASP.net(C#, 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