Overall the presentation was fine, he have a lot of good information, tips, techniques, and so on. The one part that I took issue with was where he talked about Hungarian notation. He stated that for C# programmers, Hungarian notation should not be used. His premise was:
1. C# is strongly typed already
2. Visual Studio environment gives you all of the information anyway. All you have to do is hover over the variable.
3. There was also the reason that if the variable type has to change, you then have to change the variable prefix all over the place.
Here are my argument against his.
- Delphi, C, C++, VB, Java, and many other languages are also strongly typed, but it is still considered best practice for those languages. I really like C#, but I dont believe it has done anything to make Hungarian Notation obsolete.
- Great, so now if you print out the code, how is Visual Studio going to help you. Also, why should I have to move my mouse just to figure out what type a variable is, what it's scope is when I can just look at it. If I have to take my hands off of the keyboard, you are wasting my time. Also: I'm sorry, but you should not, under any circumstances, assume that everyone reading your code will be using Visual Studio, or any other environment for that matter. With the onset of Mono, SharpDevelop, and the new Delphi environment (which supports C#) that is dangerous argument. Programmers are fickle and prone to change quickly, tomorrows Visual Studio.NET might be Emacs (or VI -- cough).
Motive 2: If I'm having trouble with a procedure I've written, I'll bring in another developer to look at that procedure. I dont want him to have to inspect the entire class just to figure out where the variables are declared. Now you are wasting the time of two developers. - Haven't any of you people heard of "Search and Replace"? It has been a standard feature for years and has become very useful to the modern programmer. Changing a variables type is not a small matter anyway. Any time you change a type you should go through every place where that variable is used and make sure that it is still going to work. Think of it this way, one of the tips that Carl gave was that when you check in your code to your source code control (Source Safe, Vault, CVS, etc), you should inspect EVERY line you changed. When you change a variable type, you have affectively changed every line that variable is used on. What better way to make sure you look over every line than to change the variable name.
I work in a large enviroment with many developers. Typically, one developer will start a project, work on it for a while, then hand it off to another developer, who has to make more changes. That second developer will have code from many other developers in his hands at once and has to be able to read it all.
Now let's be frank. C# allows developers to write some pretty sloppy code. Variables can be declared anywhere, in any form. They might be prefixed with private or public, or they might not. You can declare a exception class as IgnoreMe instead of IgnoreMeException. Curly brackets can go anywhere. C# is not a structured language. It is up to the programmers to add structure, and frankly, not using Hungarian Notation is just adding one more inconsistency variable into the mix.
To sum up: Hungarian Notation makes code easier to read and understand for other developers, removes reliance on other development environments, and up to this point, every argument I've heard of for getting rid of it has been insubstantial and petty.
If anyone cares to prove me wrong, please do.
1 comment:
I do agree with you about the usefulness of hungarian notation. I've been using it for quite a long time writing C/C++ code, and honestly I got used to it.
But I think hungarian notation also has its drawbacks.
Which do not always depend on the programming language you code with.
The main argument against the use of hungarian notation, IMHO, is that it is often impossible to use it everywhere.
Let me explain through a little code snippet (it's c#, but this does not matter, as long as we can define our own type - or maybe only simple C structs ...)
Int32 vehicleCount;
.. or ..
Int32 nVehicleCount; // iVehicleCount ...
well, hungarian notation has its advantages.
But when you have code like this:
class Vehicle { ... }
Vehicle sampleVehicle;
.. well, it's not hungarian notation, since there can not be any predefined prefix for all custom types !!
Sure, you can write code like:
Vehicle[] vehicles = GetVehicles ();
Int32 nVehiclesCount = vehicles.Length;
But you finally have a mixture of "hungarian" variables (the native types) and "not hungarian" variables.
Sometimes (I'm thinking about Windows #defined types) there are standard prefixes for other types (h*** stands for HANDLE, and so on).
However you have to face the problem of either prefixing your custom types' variables (something awful like Vehicle vVehicle, and what if you have a vValidity or a vVerification ? using vhclVehicle is just reducing the possible prefix conflict) or do not prefix them at all.
If you find a standard, homogenous way for using custom types' prefixes, well, then no problem at all.
But I think this is quite impossible, unless you only develop very small software packages (and, even if that's the case, you should always consider sharing code with other developers, maybe they might not like your choices).
So you can only have code where "nCount" and "vehicleOne" are mixed together.
Isn't it better to give hungarian notation up ?!
Unfortunately, while I agree with you (neither the "hover" way of finding a variable type nor the little effort to change its type with no refactoring are good motivations against h.n.), I believe you will write a much more homogenous code without h.n.
So, Bye !! (well ... ciao, I'm from Italy)
Claudio
Post a Comment