Hello,

I am sorry if I sound a little bit nit-picking, but I (still) have problems figuring out what name to assign to variables. Therefore, I would like to hear what some of you are doing, if that's allright.

IMO, I use three sorts of variables:

*** local (private) class variables** I declare these as: private nameValue as type Public properties of such variables are declared as Name(). For example:

private dogValue as Dog
Public Property Dog() as dog
....etc

*** local method variables** I declare these as: dim name as type For example:

dim dog as Dog

*** parameter variables** I declare these as: byval name as type For example:

Public sub Shave(byval dog as Dog) 

I think the first and the third are good ones. However, IMO the second is not, as you now have an object named after a type. Though, most of the time you can think of a better name such as Sparky: dim sparky as Dog. But sometimes you can't. For example, some "abstract" object like a "FileChecker". I can't think of any other name for it! So now I am doing: dim fileChecker as FileChecker, which can be confusing sometimes. I could however name it something like fileCheckerObject, fileCheckerObj, fileCheckerInstance, fileCheckerValue, etc, but hey... would that really clarify things up? So.... again: how do YOU name your variables, especially the second ones!?

In these situations I try to give my variable a pronoun that better describes the variable. Using your dog example:

Dim dog as Dog

Instead try:

Dim OldDog as Dog or Dim NeighborsDog as Dog

Feel your pain. I agree with Paul, first I try to find a name which better describes the instance.

For example, a hashtable containing employees: EmployeeHashtable or EmployeeCollection.

But in some examples it's harder to find a descriptive name, like the class FileInfo. In these cases I tend to name these instances FileInfo1, FileInfo2 etc as a local variabele.

I would avoid using postfixes like 'Obj', 'Object', 'Value' etc ..

In general I try to follow the microsoft naming guidelines: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp

Found this blogpost the other day about the same issue: http://blogs.msdn.com/rickhos/archive/2004/07.aspx

I'm also curious to know how others handle this issue.

MacDennis wrote:

Feel your pain. I agree with Paul, first I try to find a name which better describes the instance.

For example, a hashtable containing employees: EmployeeHashtable or EmployeeCollection.

But in some examples it's harder to find a descriptive name, like the class FileInfo. In these cases I tend to name these instances FileInfo1, FileInfo2 etc as a local variabele.

I would avoid using postfixes like 'Obj', 'Object', 'Value' etc ..

In general I try to follow the microsoft naming guidelines: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnamingguidelines.asp

Though why do you then uppercase the first character in the variable?

Naming issues are of all time. I always keep in mind that if I or someone else has to read the code in 2, 3 years time, it should be self-descriptive, at least as much as possible. So long(er) descriptive names, for variables and method names, and also classes.

It doesn't really matter what naming scheme you use, as long as you use one and use it consistently. So some people argue not to prefix member variables, though I disagree with that and prefix member variables with '_'.

Others never access local variables directly, but always use this.varname.

I must say, the ms naming guidelines are pretty inconsistent as well. Why having a 'Attribute' suffix or an Exception suffix but no enum suffix? etc.

MacDennis, that blogpost you mentioned pretty much sums up how i think about variable naming. Thanks for the link, i think i can use it as an aid in the internal discussion over here.

For abstract objects like a FileChecker i will drop in most cases a part of the name. So i would declare

checker as FileChecker

I think variable names should not reflect their type name, but their function. Especially for this kind of helper objects there is a big chance, these will be substituted for an object with a different type implementing the same interface. Example: first you are using an XmlTextReader, but later on you switch to a XmlValidatingReader.

We use an underscore-prefix for alle private member variables. I am not a big fan of this rule. May times i think: 'hey, i thought there was a variable declared for this, but i do not have intellisense on it', until i realize it is a private and type the undersore fist. However, the rule is very easy to apply, it works well in a team.

I found a great article today about .NET naming conventions: http://www.irritatedvowel.com/Programming/Standards.aspx

I have been trying to come up with a standard way of doing things for quite some time but this article hits the nail! To my surprise, I agree with each and every rule. I will definately adopt the rules as mentioned in the article. The search is over!

wvnoort wrote:

For abstract objects like a FileChecker i will drop in most cases a part of the name. So i would declare

checker as FileChecker

I think variable names should not reflect their type name, but their function. Especially for this kind of helper objects there is a big chance, these will be substituted for an object with a different type implementing the same interface. Example: first you are using an XmlTextReader, but later on you switch to a XmlValidatingReader.

You are making an interesting point here. Most of the time, naming a variable isn't hard for me. But sometimes, like in my example it is. Why is this, is wondered. I think I know why: it is just (very) hard to read.

Making the name more readable would help. For example: "FileChecker" would become "Checker". In this case I would seem a little bit redundant to do so, but think about aFileTemplateHeaderFileChecker object. What's more readable?

dim fileTemplateHeaderFileChecker as new FileTemplateHeaderFileChecker
FileTemplateHeaderFileChecker.Start()
...
FileTemplateHeaderFileChecker.Pause()
...
FileTemplateHeaderFileChecker.Stop()
...
FileTemplateHeaderFileChecker.Cleanup()
...

or ...

dim checker as new FileTemplateHeaderFileChecker
checker .Start()
...
checker .Pause()
...
checker .Stop()
...
checker .Cleanup()
...

The problem in doing this is that there is a conflict if you have more then one "Checker". For example, a "Filechecker" and a "FolderChecker". Now reading a pattern book (Head First Design Patterns: very good book: I recommend reading it!) the question came to me: What if I were to encapsulate Checker objects' creation? By doing so, I would talk to an interface instead of an implementation and let the "controller" not worry about the different Checker objects (names), but to a single Checker interface. Does this sound reasonable?

BlueCell wrote:

The problem in doing this is that there is a conflict if you have more then one "Checker". For example, a "Filechecker" and a "FolderChecker".

Well, if this would be the case, refactor and name the objects "FileChecker" and "FolderChecker".

I had the same issue yesterday. A simple example, I had an object named 'folderInfo' but then I also needed the folder information of the childs. I renamed 'folderInfo' to 'parentFolderInfo' and added 'childFolderInfo'.

MacDennis, thanks for the great link regarding naming conventions. I think I'll use it to.