|
You say "In Java, use a lower case first letter and mixed case", but, in fact, the established convention is using an upper case first letter for type names (such as for classes and interfaces).
Why is this convention (which also holds in C++) ignored by Microsoft C#?
|
|
|
|
|
You are so right.
But total price = Price * Units * tax;
But tax < 1, so it should be along the lines of: total = Price * Units * (1 + tax)
Being in the first funciton, it was kinda obvious it was not quite right.
You are calculating the tax, not the price.
|
|
|
|
|
Thanks for noticing the error Kirk. I will try to get that corrected soon!
|
|
|
|
|
If I develop and maintain code both in JavaScript and in C#, why shouldn't I use Hungarian notation, since it is the established convention for distinguishing between the names of classes and the names of methods, parameters and variables in Java and JavaScript?
Microsoft just says "DO NOT use Hungarian notation". Why not?
|
|
|
|
|
Hi Gerd, I am aware of two reasons that Microsoft recommends not using Hungarian notation, but there may be others:
1) It is not common in C# code and thus is distracting and a little confusing for C# developers not familiar with the practice
2) Intellisense in Visual Studio provides information about the data type of the variable. Hungarian notation could be incorrect if a developer initially uses the wrong notation, or if a developer changes the datatype of a variable without renaming it.
There are no absolute rules in programming. If Hungarian notation is a better solution for the software you are working on then you should use it. Best practices are just intended to provide guidance to developers that have not given a lot of thought to all aspects of the code they are writing.
|
|
|
|
|
Also to add to the previous comment. Not only might the original developer have gotten the notation wrong, the type may have changed. Many, many times when I was forced to used Hungarian by coding standards at in a job or project the actual type of the variable changed out from under the name of the variable, thus leaving us with the choice - wrong notation or changing hundreds or thousands of references scattered across multiple source files.
Even with limiting scope of variables and better tools do you really gain that much from the notation that it is worth the risk?
|
|
|
|
|
Thomas Chizek wrote: Many, many times when I was forced to used Hungarian by coding standards at in a job or project the actual type of the variable changed out from under the name of the variable, thus leaving us with the choice - wrong notation or changing hundreds or thousands of references scattered across multiple source files.
Even with limiting scope of variables and better tools do you really gain that much from the notation that it is worth the risk?
In today's multilingual development environment, other issues favor retention of some measure of Hungarian notation. Please see my essay on this subject, Multilingual Mania[^], and The Reddick-Gray Unified Naming Conventions[^] I shall confine my remarks herein to one issue, that of code reviews, in which you work in a conference room, and probably from printed listings on which reviewers made handwritten notes. If you are lucky, you have a live Visual Studio screen projected on the wall, but I suspect that many reviews happen without such benefits.
I am not suggesting wholesale use of Hungarian notation, and this has never been part of my practice. My usage is along the lines of those mentioned by Kirk, elsewhere in this thread; object , property, and method names are MixedCase, internal names (arguments, class storage, and locally scoped variables) are Hungarian CamelCase, and constants of all stripes are UPPERCASE.
|
|
|
|
|
Which is fine, but not Hungarian. It is a derivative that attempts to solve the problems of the original. So you are not saying "use Hungarian" you are saying "use this other naming convention that is somewhat related in a vague way to Hungarian". Sorry in my opinion you are arguing at a strawman, making up your own definition to be what you want it to be.
|
|
|
|
|
It is Hungarian, tempered by over 35 years of hard won real world experience. Applying any standard or convention rigidly is unwise. A great deal of thought and study went into the conventions that I use. Look at Kirk's comment, then read my entire essay and my conventions before you jump to conclusions.
|
|
|
|
|
Sigh, look I have over 30 years of real world experience as well. I did read your article, I do understand your conventions, agree with them, and use something similar to them. What I am objecting to and this is a general objection that you are catching the brunt of is the generalization of this type of naming standard as "Hungarian". There was a very specific naming convention that had/has that meaning, I (and it sounds like you) lived through the time period when it was all the rage. Calling these variants Hungarian makes the younger programmers confused as to what the convention actually is and why people who lived through it dislike it so much.
I didn't explain this very well, and I should probably write an article explaining my dislike of this kind of generalization. While my opinion will not have an impact on the overall industry this particular thread caught my eye on a day when I was feeling particularly old and grumpy about people that I thought hadn't lived through what I consider "Hungarian Hell" making comments. So I shot off my first two before rereading your article - for that I apologize, however from my read of your article all you did is repackage the prefix ugliness of Hungarian which is one of the parts of it that I truly dislike.. What I don't apologize for is my dislike of everyone calling these naming conventions Hungarian, in my opinion you should find a different name or not jump into articles about not using Hungarian.
|
|
|
|
|
I wondered if it might be that you were venting, and I understand your frustration; I was feeling pretty old yesterday, too. I don't call mine Hungarian notation, although I refer to that as the starting point from which Greg Reddick derived the conventions that were my starting point. Not only did I live through Hungarian hell, but I have actually read, more than once, "Hungarian Notation," by Charles Simonyi, which is still accessible at https://msdn.microsoft.com/en-us/library/Aa260976(v=VS.60).aspx[^], and still worth reading.
Thank you very much for clearing the air. I think all of us (you, Kirk, and me, anyway) are on the same page.
|
|
|
|
|
In College, we programmed our Memory Manager using HPN (Hungarian Prefix Notation).
And it spilled over to the entire project.
It was a WONDERFUL THING. Our code was SOLID, and easy to read.
But it was C code.
When you move over to OOP, you have properties. And how a property is stored in memory is far less important. Also, you use setters and getters more. The concept of lpszUserName being the property of a class that has a UserName attribute is not clear. And it lumps things by type with IntelliSense. Not by what you are looking for.
As I transitioned to OOP, I slowly dropped almost all HPN. I say almost for a reason.
When designing GUI elements, I name them with prefixes (btn,edt/txt,lbl,grd,etc. because WHEN
I want to start using one of the HUNDREDS of screen components in my editor, I start with btn and
use AutoCompletion.
I will also use it when I declare local variables of complex types.
I just don't use it in classes. My code has iniFile, regFile, lstLines,
and things like that. As LOCAL variables.
Now, that is not formal HPN. It is simple prefixing. It makes the code very easy to read.
It makes constructor/initialization ERRORS very obvious.
I just don't believe it makes as much sense in an OOP world with strong typing.
Oh, the memories. Thx
|
|
|
|
|
the same is for constants, functions and classes
|
|
|
|
|
KarstenK wrote: the same is for constants, functions and classes
Not so, IMO. Since IntelliSense doesn't identify constants, and it is important to know which variables are constants, they must be distinguished in some way. If you dislike constants, another alternative is some sort of Hungarian prefix, such as c , c_ , or cnst .
Please see also my reply in the "Hungarian C#" thread.
|
|
|
|
|
Great Work
|
|
|
|
|
I can never stress this one thing enough with older coders ( and younger alike), the ones who are used to and entrenched about using i_idx, j, k, x and so forth as variable names. hope this article helps in the debate!
|
|
|
|
|
Tom Granados wrote: I can never stress this one thing enough with older coders ( and younger alike), the ones who are used to and entrenched about using i_idx, j, k, x and so forth as variable names.
I resemble that remark!
However, I have adapted with the times, and I invite my colleagues of all ages to do the same.
|
|
|
|
|