Frans is talking about ceasing the use of HN. Variable naming is a pet peave of mine, especially when HN is misused; indicating type as opposed to intent. For example, most VBers assimilated something like the following for integral values:
int for Integer
lng for Long
etc.
The above HN prefixes tightly couple the type to the name thereby necessitating the renaming of the variable should the type change. Unfortunately, I've seen many cases where they simply left the prefix alone and changed the type (analogous to out-of-sync comments).
VB isn't alone in this regard, as much of the Win32 API is riddled with WORDs, DWORDs, etc. with their respective prefixes 'w' and 'dw.' Instead, I prefer to use a prefix like the following:
n for Number
s for String
h for Handle
etc.
This is similar to some of the HN styles you see in C code. The difference is that it shows intent, not type.
Frans had issue with reserved keywords when declaring a variable sans HN:
Well, a little. I'm still convinced Hungarian Coding is necessary. F.e. I had an input parameter 'iOperator'. You can't change that to 'operator' because that's a reserved keyword.
While I can certainly understand that, I have to argue that "operator" is not a very descriptive name. It seems ambiguous, so I would further quality it: operatorID, operatorName, operator. I try to follow the camel-cased variable naming format of entityAttribute or attributeEntity. I admit I don't have a standard that I follow, but the following would be good names in my opinion:
inputFilename
filenameInput
employeeAge
etc.
Of course, the use of the entity name is not always needed as it would be superfluous to name something employeeAge in class Employee.
Member prefixing is another advantage, however you can also have that with your caMel cased members, f.e. by using a '_' prefix.
I've never enjoyed the use of _ prefixes for private fields either, but it seems most prefer this style. I've always preferred to be explicit as possible. What follows is an extremely contrived example:
public class Employee
{
private int age;
public Employee(int age)
{
this.age = age;
}
public int Age
{
get { return this.age; }
set { this.age = value; }
}
public void DoWork()
{
this.DoInstanceWork()
Employee.DoStaticWork()
}
public void DoInstanceWork()
{
}
public static void DoStaticWork()
{
}
}
Explicit and unambiguous. When I reference instance members, I use 'this.' When I reference class members, I use the class name. This ensures that there is never an ambiguous reference to a member when there are locals of the same name.
Any opinions on this style?