.NET Naming Conventions

Part of learning a new programming language is adopting the various industry best practices. The naming conventions used during software development can have a huge impact on future maintenance efforts. If no rules are followed then it becomes that much harder to read the code and figure out what is going on. This particularly important as developers with different skill sets come and go from IT departments.

Back in my Visual Basic days, the Hungarian style of naming variables and such was generally accepted as the way to do things. And in most cases I agreed. Sometimes people used the guidelines in redundant ways. For instance, class files would be named clsSomeClass.cls. The .cls extension is mandatory so why bother with the cls prefix? Anyway, it wasn't a huge deal, but something that I didn't agree with.

With the introduction of .NET, Microsoft has published a new set of naming conventions. They've dropped the Hungarian style of naming. Their reasoning is that the IDEs used for writing code these days are robust enough to provide data type specific information and so there's no need to encode such information in variable and object names. They also say that dropping the data type information will improve code portability.

Microsoft is right. The IDEs are pretty good these days. In particular, Microsoft's Intellisense does an excellent job of providing hints as to what should be typed in. So now all I have to do is drop the habit learned over several years of prefixing everything.

[Update November 13, 2003]
Microsoft's guidelines seem to completely ignore Windows forms programming. This is a strange oversight given that much of what's developed for Windows is forms-based. Anyway, the problem with the naming guidelines is that they don't describe how to handle a label and textbox that are related and should have a similar name. In VB 6.0, you'd probably call them lblName and txtName. But that's using Hungarian notation, which Microsoft seems to be moving away from. Unfortunately, I don't know of a useful alternative so it looks like Hungarian for form controls and Microsoft's guidelines for everything else.

1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 4.00 out of 5)
Loading...

8 Comments

  1. @ Andy,

    I have been following the same convention of using a suffix instead of a prefix, and greatly prefer it to Hungarian- or Lack-Of-Notation. Mine is very similar to yours except that I use "-Field" instead of "-Value" For example:

    Dim mFirstNameLabel as Label
    Dim mFirstNameField as Textbox
    Dim mFirstNameValidator as RequiredFieldValidator

    I have yet to come across anyone else who uses this notation though, which makes it very hard for me to promote it. All of my colleagues want to use Hungarian notation, and, of course, they all have different interpretations of it, which is one thing I'd like to change. Have you seen any other examples of people using this style?

  2. My suggestion for controls is to use a suffix rather than a prefix and to group things by logical name. So for example FirstNameValue and FirstNameLabel, and SupplierDetailsFrame containing SupplierNameValue, SupplierAddress1Value etc.

    The advantage of avoiding control type prefixes is when you change the type of control, so if a simple textbox becomes a drop-down list the name stays the same, e.g. CountryValue rather than txtCountry or cboCountry. It also makes it easier to read the code.

    Of course in .Net it's easy to change control names in the code window so whatever approach you adopt can easily be adapted.

    For variables, I generally just use the full type name in pascal case, so dataSet as DataSet where you only have one rather than ds and sqlConnection rather than conn.

  3. Can anyone provide me with a list of naming convention as per Microsoft pattern?
    like string strTemp;

  4. http://support.microsoft.com/kb/q110264

    good start for beginners, direct from the horse's mouth. i, too, like Hungarian notation for components only, and drop it for everything else. the variable name should be self-explanatory. the only exception i make is for pointers in C/C++.

  5. Well I have also been searching for some good recommendations on naming conventions specifically related to controls. I still like the idea of Hungarian for controls and like the idea of dropping it for everything else. I like it for controls because I can find my control in IntelliSense very quickly by typing the prefix. As for local variables, functions should be small anyway so finding its type should be in a single screen's view, in addition to the IntelliSense tool tips when you hover over it with the mouse.

    The bottom line however is that is comes down to personal choice. If you find a good naming convention you like, stick with it and be consistent. If you are like me however, you will change with the times and use new conventions, as they become more mainstream and standardized. Sometimes the reason for having the older naming conventions is no longer justified with the newer technology.

  6. Does anyone know where there are standards for naming VB.NET controls, or do we just stick with those left over from VB6?

  7. Nice little piece of writing. I like your opinions and point of view. I've maintained a strict coding standard for myself and my developers, and have maintained the Hungarian-style naming conventions for components: Windows Forms and ASP alike. All other object types are excluded and we follow the new, truncated variable naming.

    I've personally found it easier, and slightly more enjoyable to go back to coding my variables as "o" for object and "s" for string, and the ever-so-simple "i" when iterating a for-statement. 95% of class members should be under 15 lines of code anyway, so local variable name conflicts are generally non-existent. I might add that the truncated form of object naming also alleviates the annoyance of changing a variable type (e.g. intNumber to lngNumber).

    It seems as the object models in our foundation classes increase in size, even intellisense becomes bothersome to trudge through when looking for the name of a component, such as a text box, so the Hungarian-Style naming convention maintains some seniority in that arena.

    Overall I'm pleased with Microsoft's .NET standards.

  8. I sure like knowing if the variable I'm looking at is a number (intVideoBay) or a boolean (bReady). Also, when coding a Windows form, I like to be able to locate my controls in the Intellisense drop-down by using the Hungarian prefix. I plan to continue using the Hungarian for those three reasons. I suspect that Hungarian will come back into fashion in 3 years, so I'll just hang on to my old habits for a while.

Leave a Reply

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail.