Code of Conduct (The Project Saga - V)

(Posted in Office Blog on March 2nd, 2007)

Recently I was going through the revamped .Net CoE Portal, well the first opinion was the looks were good and more updates on various topics.

But the fact the inspired me to write this blog entry was the Coding standards paper put over there. Before I go on to describe my views, let me make some statements

1. It is good to see that they are keeping the site upto date with latest .Net Framework and new set of standards. When I was in my previous project, the site had very less information on VS .Net 2005 and conding standards for that.
2. I come from a C background and my points of view might be inspired from the standards that I am following there.

All said and done lets get down to some of the issues that I felt that need to be addressed in the Standards (Will be covering C# for now)

1. Variable Naming Convention
   No separate Section for variable naming convention is to be seen in the CoE Coding Guidelines for C# document. It would be good if they could introduce a section on Variable Naming conventions covering Local Variables, Global Variables….etc
   
   
2. The “Hungarian Syndrome”
   I know you guys are about to pounce on me and have me for dinner if I pronounce the word “Hungarian.” Microsoft Explicitly says “Do No Use Hungarian Notation Anywhere” , well then you ask Why am I bringing up this issue again. Let me tell a small story first.
   Everyone must be familiar with the infamous “goto” statements we all have been warned not to use it and those who used it have suffered from the hands of their seniors. There was even a paper published by “Edsger W. Dijkstra” in 1968 telling that GOTO statement is harmful and must be eliminated from programming languages completely, but this was counter acted by one of my favorite heros in the world of computer science ”Donald E.Knuth”, In 1974 with the paper “Structured Programming with GOTO statement”, he analyzed various tasks in programming which could be optimally written using goto.

The lesson from that story is that if you use GOTO intelligently you can make efficient and readable codes, but the fact is not to use it as and when you please, do it and it is like shooting the gun at your foot and believe me its gonna blow your foot off.

Well Hungarian Notation is not as much dangerous, but the point I am trying to say is with power IDEs like VS .Net the need for Hungarian Notation is long lost and its not required but the IDE is not going to be there always for you. This is where the problem comes, when you are going through your code using editors like Textpad or Notepad which is a very basic text editor and your code is very lengthy, you might loose track of your variable’s type. A typical scenario was there in my previous project where during the deployment of a Web Service in a Deployment server only with IIS and the .Net Framework they had problems with the code behind and they had to go through the code then and there on the server which had no IDE installed.

If you are convinced that this is a problem that can happen and that to too often, it is then the Hungarian Notation comes to your rescue. Now I dont recommend using the Hungarian Notation everywhere but I do recommend using it when you are using local variables in functions and private instance variables that will be acted upon in the classes. As far as parameter passing in concerned my stand point in Neutral, coming from a C background I am still a Hungarian Follower but had to change my style to adapt to the new environment.

Hungarian is still followed in SQL Server 2005 coding standards draft in .Net CoE Portal and I appreciate that and I believe it has to be followed to a minimal extend in C# also like in local variables, global variables, instance variables etc…(These are just suggestions ofcourse.)

3. To Underscore or not to Underscore
   Now that is the Question at hand, once again underscoring is not such a good practice, but it is necessary when required. This is one place that I disagree with Cognizant once again. They say underscore should not be used anywhere, except when separating words in constants like “MAXIMUM_VALUE” (using CAPS is another issue)But from various websites I have gone through on Coding Standards, I have understood that it is a good practice to have a leading underscore in the private variables of classes. I found that this was particularly useful while you are debugging programs with a leading underscore you can identify your private variables of a class instantaneously and not mistake it for the same variable’s Property, usually differentiated using a camelCase for variable and PascalCase for Property of the same. Same applies to the protected variables also.
   
   
4. CAPS or small
   Well yet another neutral point, again in C I use ALL_CAPS when doing “#define”s and “const”s, but in C# I have read that this is not an usual convention. It was said that name the constant just as another variable and then attach the word constant to the endLike for example camelCaseConstant, It looks more elegant and confirms to Microsoft .Net Back in the old project the FxCop Tool actually threw out errors for having ALL_CAPS constants.

These were some of my viewpoints on the Coding Standards for C# set by CoE. Do let me know if they are acceptable or not. Till then bye…

References

1. .Net CoE Guide Lines (Center of Excellence in Cognizant)
   
2. irritatedVowel (This Guy has a real nice site on Coding standards)

For those who are interested you can find the GOTO Papers here in Wikipedia, the papers are the bottom of the page