Pierre-Emmanuel Dautreppe

You may know one of the improvement of Sql Server 2005 was the tight integration with the .NET CLR, giving the ability of creating stored procedures in C#.
We have never used in production environment and it's time to exchange on this subject.
One of my colleague will give a training on this subject

You would like to attend ? Leave a comment !

.NET has introduced since its very first version the concept of enumerations. It's of course quite nice and allow us to replace magic numbers in the code by self documented structure.

But their use is far over too common, without thinking before to the consequences of such a choice.
First people usually think that using an enum as a function parameter restrinct the range of the accepted values. Wrong.
We all know unfortunately that developpers use something without knowing all of it.
But this is not my main concern with enumerations.

Starting to use an enum will of course lead to some points in the code to conditional code, either using a "if / else" structure or a "switch" (please don't forget the default !). And this conditional code will soon start spreading all over the code.
And what happen if you had later on a new value to the enum ? You should check (and potentially update) the very numerous places where you have been using it to update acordingly the conditions to let it continue working with the new value.

OO and centralized code you have said ? No, no longer.

I won't discuss here more in detail this problematic as we have decided to hold an open discussion next tuesday (11th September 2007) either in Charleroi or in Brussels to address this specific point.
Interested in participating or in exchanging on this subject ? Please, leave a comment !

You probably create regularly new objects. Let's imagine you create a new class like this :

Of course you will use it and you will want in some moments to debug and see the value of your class. By default, here is what the debugger watch will show :

So of course, you know that the ToString method is used for the display and will update your object definition with non-fonctional - and probably not tested - code, to have a nicer debug display.

 

So you are now writing kind of debug code in your production environment. Definitely an error.
So let's remove the ToString method and let's achieve that differently !

And here it is ! Now your application contains only functional code and you can also have a nice debug experience !
Note that you can use the syntax "{name}" where "name" is either a internal member, a property, ... on which Visual Studio will call the ToString() method if necessary.

So to conclude, your application should never contain debug code. You may want to use the "ConditionalAttribute" or the "#if" syntax, but the best is not introduce debug code. And in such a case, the DebuggerDisplayAttribute is probably the solution that will perfectly suits your needs !