Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Naming Conventions in .NET

I'm a fan of type defining in my variable naming, ie
dim lngCounter as Long or dim strLastName as  String.
Balena says that this is no longer necessary in .NET as the IDE tells you the data type when you hover the mouse curser over the variable, have those amongst you that are developing .NET applications dropped this convention, thoughts?

Also, in VB6 when defining a typical collection/class for say a person it would be conventional (for example) to have a CPerson class defining all the attributes of a person, and a CPersons collection class to hold the collection. This can be done in .NET using Implements System.Collections.IEnumerable in the collection class,
but it is no longer necessary to have seperate files, these two classes could be defined in a single class, in fact as you will know .NET allows much more flexibility in the class structures within an application, a lot more class definitions can be bundled into a single class. How are the experienced VB6 programmers using this capability? Is it best to stick to the Persons/Person being two different classes? I'm just trying to get a feel for how a OO .NET application might look (say in the solution explorer) to how it would be structured the 'old' way.

Friday, October 11, 2002

I still stick to the Hungarian notation from coding MFC:

1. Use txt, lbl for textbox and label variable prefixes.
2. Use i, s, l for integer string and long variable prefixes
3. Use m_ for all class member variables

I do this because it makes the code easier to read and you can look at the variable name and determine what type it is and what scope it is in (local or class (m_)).  The downside is that you could screw up the variable names.

Saturday, October 12, 2002

I use a single character prefix denoting scope:

sVarName = static (class) scope
mVarName = member (instance) scope
pVarName = parameter (method) scope
tVarName = temporary (sub-method) scope

I also use a few standard names for things like loop counters (i, j, x, y, etc). 

This prevents name collisions and gives me a pointer to where I should look for a variable declaration.  Never liked the hungarian notation, myself, for a variety of reasons.

Sunday, October 13, 2002

I guess you've read this (in a nutshell, no more hungarian notation):

I follow that standard pretty much, even when not in an ide, and it has been great so far anyway. The only problem I had was when targetting cls, you must be case insensitve, so I ended up calling the private data of get/set accessors things like '_name' and '_id' (mapping to Name and Id).

Robin Debreuil
Sunday, October 13, 2002

If you've got a lot of time on your hands, read Steve McConnell's book "Code Complete".

If you don't, read the whitepaper "Design Guidelines for Class Library Developers" from Microsoft.

Guy Incognito, MCSD DOA PITA
Sunday, October 13, 2002

Thank for the links, I have read some before.
I think I'll stick with hungarian as we do formal code reviews around here (hard copy printouts to reviewers where everybody can get out the red pens go for it)
(we all get on pretty well fortunately) and I think it increases readability, especially when skimming.

Monday, October 14, 2002

I would humbly suggest that the hungarian convention only increases readablility until version 2.0, when you have to change the type of lngTotal to a float.

Then you get stuck having to either:

1) Change ALL the variable names in the app (long, and counter productive)


2) Leave the variable name alone.

In my experience, #2 is inevitably the way chosen, and then you get confused later when you read the code and wonder why you're getting floating point rounding errors from a long.

Hungarian doesn't work when types change, and they change all the time in maintenance.

Chris Tavares
Monday, October 14, 2002

I've always hated Hungarian notation.  Nevertheless, there are two conventions that I've always used in C++: m_ as a prefix for member variables, and g as a prefix for global variables.  I'm haven't used either of these in .NET for a very simple reason: they're not necessary.  You can always identify a member variable, because they're not defined in a different file anymore, and there aren't any global variables.

There's a Java convention I really like; classes start in Uppercase and members start in lowercase.  This allows these to be quickly and easily distinguished.  I wish .NET had adopted the same convention instead of capitalizing everything.  I started out writing my own code that way, but it just looks wrong when you scatter in a bunch of calls to the CLR.

A pox on programming languages with case-independent identifiers!

Curt Hagenlocher
Tuesday, October 15, 2002

Just to throw in point of view: I dropped hungarian when I moved to object oriented programming. Although I still use a naming convention, the HN system doesn't appl very well to modern languages.

If you take a moment to look at the reason for hungarian notation, it was intended to support development in a type-weak environment, where strict type-checking was simply non-existent. A strict naming convention would have two independent programmers eventually coming up with the same name for the class or variable. That in mind, is is clear that such a system will only be usable if there is a strcit type prefix for each and every type in the system (which is not in many programmers' sources) and there is a standard for the types that is accepted within all members of the development team.

Having modern languages like (these are jsut examples, not starting points for language debate!) Delphi, C# and Java, with string type checking, an IDE with data type support, shared development environments, the need for a strict type prefix decreases. Of course, this does by no means mean to break eternal laws like using "i" and "j" for short-code loop indices, but there is no need to support your brain with hungarian when you have better suuport tools within your reach. To admit it, I still use prefixes for controls like chkBackupDataFile or lblWebURL ...

My next reason to drop hungarian (mostly, as you may have noticed) is the fact that code is read much more often than it is written. So code should be definitely read-optimized. All that "tricky" in developer discussions IMHO is just a synonym for "not maintainable". "But hungarian gets you better readability", I can hear you; "Well, longer and more informative identifiers are even more readable, especially for skimming over code. Just compare a statement like lngPg = dpDocObj.collObjPages[lngPgNo]
to  PageIndex = CurrentDocument.DrawingPages[ActivePageNo]

I do not need the data type because I can tell from the names what this code does. One of my greatest fears is that vowels will become extinct some time because we developers forget how to use them in identifiers! :-))

I agree with you in one point: I like to do code reviews and refactoring skteches with a fountain pen on a POP (plain old printout) and at that point sometimes a data type quicktip would be very handy. But if you have a good meta data repository (and a nicely formatted printour with you) it's a little better. I'm still trying to find a way. Another advantage is if you have to browse thru code with the customer or use some code in training classes: read-optimized code without prefixes and meaningful names is actually easier to understand.

Last point after somebody before me mentioned Code Complete (one of my favorites also): read "The Pragmatic Programmer" from Thomas/Thomas. Very good book!

Sorry for some language glitches, but if I would have written that in German you probably would have even more problems trying to figure out what I mean :-)

Armin Hanisch
Tuesday, October 15, 2002

I've basically dropped the hungarian apart from controls (which seems to be common) I must admit that it's been tough to change, somewhere in my brain there's a sinapse or neuro transmitter that just automatically types 'lng' when I'm thinking that it's going to be a long variable type.
Ah well, maybe my hands will thank me for all the typing I'll be saving them.

Tuesday, October 15, 2002

Yes, my convention is give a variable sensible name in the firts place and you don't need ugly prefixes, etc. I follow most of the .NET guidelines (camel case here and pascal case there). For controls I use suffixes instead: usernameTxt, discountLst, feedbackLbl, etc...

One thing that drive me up the wall is code that uses names like "objConnection" -- Aaarrggh! *everything* is a object!

Wednesday, October 16, 2002

What I always found weird about hungarian is you go to great pains, using get/set, oo etc to hide the fact that your real data is an int or long or whatever, then you turn around and name something lngValue... I mean are we trying to hide this or not? I didn't ever use hungarian notation much - if that is obvious from my logic forgive me in advance...

Robin Debreuil
Wednesday, October 16, 2002

Basically I'm going with camelCase and PascalCase now, camelCase for parameters and PascalCase for function names, variables..etc

Thursday, October 17, 2002

At least for controls and ADO.NET objects, I've gotten into the habbit of using readableNameType rather than the Hungarian-style typeReadableName. Intellisense isn't too useful if you've got a stack of lblWhatever or txtWhateverElse controls, but I like having the type info for variables that aren't of primitive types.

Dave Rothgery
Thursday, October 17, 2002

Reading the coding techniques article by Rob Caron, referred to above, I came across this beauty.

"When writing HTML, establish a standard format for tags and attributes, such as using all uppercase for tags and all lowercase for attributes. AS AN ALTERNATIVE, adhere to the XHTML specification to ensure all HTML documents are valid. "

The capital letters are mine. The world's most important software organization suggests adhering to international standards is AN ALTERNATIVE. Jeez!

Stephen Jones
Thursday, October 17, 2002

Err, when writing 'html', which isn't case sensitive by spec, you can choose to conform to the 'xhtml' spec, which is case sensitive and requires all tags and attributes to be lowercase. Note that the xhtml spec does not cover html... It is just a reasonable alternative suggestion to consider.

Robin Debreuil
Friday, October 18, 2002

Formatting HTML is not the same as formatting VB or C++ code you write for your program. in the latter case your source code is only going to be seen by you and other programmers. Your users will just get the binary .exe and won't care less what format or even what language the program was written in.

But HTML code stays up on the internet and must be interpreted by the user's browser every time he accesses the page. And as a coder you want your code to be write once, display everywhere, which is precisely why you have standards.

If Microsoft are opposed to the XHTML standard, (and certainly having tags in capitals and attributes in small case makes for better readability) then it should have opposed the prohibition on upper case tags to start with.

What you are opposing is a system like Indian traffic regulations. In theory in India you drive on the same side of the road as in Britain, but the only way you could ever find out which side of the road you are supposed to drive on is to see where the steering wheel is in the cars.

Stephen Jones
Friday, October 18, 2002

You're "proposing", not "opposing". Indian driving practice.

Perhaps we ought to launch a campaign to change Joel's mind about having a preview for replies!

Stephen Jones
Friday, October 18, 2002

They helped define the xhtml spec, I don't think they oppose it? Html being case insensitve happened long before they came along, though I think it was a good decision (given that html is meant to be simple, universal and tolerant). It is no different that suggesting that people use <br/> or <br></br> rather than <br> - all are valid html but the first set is also valid xhtml (though the double one breaks in some browsers).  By writing non-typical and perhaps less readable html you can get valid xhtml - it is going to be a trade off though. I don't think one should read much more into it than that ...

Oh, sign me up for the preview button campaign! : )

Robin Debreuil
Friday, October 18, 2002

The fact of the XHTML specification being ignored even in the textbooks teaching you how to code HTML was mentioned in an article on somebody linked to from this forum only a little time ago. The XHTML specification was set out in 1998 and the MS coding article I am referring to was published in 2000 (and has apparently never been revised).

The reason for following XHTML is that the game plan is for the net to migrate over to XML, which is case sensitive, and doesn't allow upper case in tags. Code that is XHTML compliant will be compatible with past, present and future browsers. Code that is only HTML4 compliant may not be.

The rule in XHTML is that all tags must be terminated. However there are some tags, such as the <br> or <img> tag that don't have any content (as opposed to tags such as <td. or <p> that may be empty but can also have content). The way to close the former is to close them within the same tag <img src="Melookingcheesyphoto.gif" /> or <br /> The blank line is necessary not to confuse present and older browsers, but later browsers will parse out the blank space.

Stephen Jones
Friday, October 18, 2002

*  Recent Topics

*  Fog Creek Home