Hungarian Notation Should I use it?
Pages: 12
So I was reading this http://www.learncpp.com/cpp-tutorial/29-hungarian-notation/
and I started wondering should I be worried about my naming style? I don't want to develop bad programming habits so before I learn Hungarian Notation I would like the ask the experienced users what they think. So should I learn and use Hungarian Notation or just ignore it?
and I started wondering should I be worried about my naming style? I don't want to develop bad programming habits so before I learn Hungarian Notation I would like the ask the experienced users what they think. So should I learn and use Hungarian Notation or just ignore it?
Whatever you do just don't use Microsoft's version; it is useless to put the type of a variable in its name.
The link you posted is the wrong version of Hungarian Notation (Systems Hungarian) - the older one is the correct one, try to find it (Apps Hungarian).
The link you posted is the wrong version of Hungarian Notation (Systems Hungarian) - the older one is the correct one, try to find it (Apps Hungarian).
Last edited on
Ignore it almost everywhere. It's not as problematic when limited to simple things like bool or int, but for more complex types, you don't want to tie down the type to the identifier, specially in public interfaces.
Additionally:
1. Descriptive names are a lot more useful than Hungarian.
2. If your function is so long that you can't see all the variable declarations, you have bigger problems than naming.
3. If you're working with an IDE, hovering over a name is usually enough find out its type, and it works much better.
EDIT:
Personally, I don't agree with that solution. Since all user strings are supposed to be unsafe, make the user input function return unsafe_string and the write function take a safe_string. Then you just add
I don't know if that's possible in the language mentioned there, but that's how I would do it in a language with strong typing and user types.
Additionally:
1. Descriptive names are a lot more useful than Hungarian.
2. If your function is so long that you can't see all the variable declarations, you have bigger problems than naming.
3. If you're working with an IDE, hovering over a name is usually enough find out its type, and it works much better.
EDIT:
| http://www.joelonsoftware.com/articles/Wrong.html |
safe_string encode(unsafe_string) and done! Now semantically incorrect code doesn't just look incorrect, it doesn't even compile.I don't know if that's possible in the language mentioned there, but that's how I would do it in a language with strong typing and user types.
Last edited on
@LB Thanks I liked the article totally going to my bookmarks.
@helios Alright I'll just make my names for descriptive instead of Hungarian.
Any other suggestions?
@helios Alright I'll just make my names for descriptive instead of Hungarian.
Any other suggestions?
I disagree with helios's assessment.
There is a difference in strings. It is true that anything you get from the user is unsafe. But once properly sanitized, however, they do become "safe"; now it is the programmer's responsibility to make sure it is used properly.
Part of Joel's point was that taking the time, energy, and code to force an actual type incompatability for a semantic difference is a waste. After all, the same thing happens with other types -- some double values are not "safe" -- that is, are out of range -- when used with certain <cmath> functions, and yet we don't encode type information into them to prevent out of range inputs. That would be total nonsense.
And you cannot claim that this is comparing apples and oranges. The type of a thing is not so important as the validity of its value. If you pass a bad double value that you got from the user into certain functions, you can undermine the function and/or security of your program just as well as passing a bad string value that you got from the user into certain functions.
Obligatory comic:
http://xkcd.com/327/
There is a difference in strings. It is true that anything you get from the user is unsafe. But once properly sanitized, however, they do become "safe"; now it is the programmer's responsibility to make sure it is used properly.
Part of Joel's point was that taking the time, energy, and code to force an actual type incompatability for a semantic difference is a waste. After all, the same thing happens with other types -- some double values are not "safe" -- that is, are out of range -- when used with certain <cmath> functions, and yet we don't encode type information into them to prevent out of range inputs. That would be total nonsense.
And you cannot claim that this is comparing apples and oranges. The type of a thing is not so important as the validity of its value. If you pass a bad double value that you got from the user into certain functions, you can undermine the function and/or security of your program just as well as passing a bad string value that you got from the user into certain functions.
Obligatory comic:
http://xkcd.com/327/
When I read on the Hungarian notation, I was fed the Systems version and thought it was ridiculous. Now that I've had a proper explanation, I'm definitely going to try to use it in future projects.
I always try to keep some clarity in naming conventions, especially for looping indeces which are often lazily called 'i', or a number version for nested loops, but I have yet to find a good way to stay consistent. Especially when you start mixing indeces from several tables that are sorted differently, index-juggling gets very confusing and often leads to nonsensical behaviour.
I always try to keep some clarity in naming conventions, especially for looping indeces which are often lazily called 'i', or a number version for nested loops, but I have yet to find a good way to stay consistent. Especially when you start mixing indeces from several tables that are sorted differently, index-juggling gets very confusing and often leads to nonsensical behaviour.
Anyway thanks again guys I really appreciate you guys sharing your wisdom.
Last edited on
Hungarian seems to have gone out of fashion. Everyone I've met over the last few years tend to use Camel-case; the Java generation.
| Hungarian seems to have gone out of fashion. Everyone I've met over the last few years tend to use Camel-case; the Java generation. |
So does the .NET generation developers still use Hungarian or Camel-case ? I personally feel Camel-case is neater and human-readable without cluttering too much valuable screen space when we look at lines of code. And yes I do use ' i ' as index for for loop and I think is ok since it is confined only within that for loop.
| Fashions change. |
Well it applies to IT isn't it? We used to have C -> C++ -> Java -> .NET and then we have CORBA,SOAP,RPC-RMI,REST and etc etc etc.
But the Computer Science fundamentals doesn't change. We still have our algorithms and data structures. Perhaps procedural -> Object Oriented and not much more. But one thing is certain abstraction layers are building up until nowadays graduate developers are working at a very high level. There is nothing wrong but when special situations call for going under those levels, they will be lost.
Hungarian notation is bad. It might seem like a great idea at first but as time goes on, I assure you, those variable names cannot be trusted. If you have to look up the declaration anyway, it is not beneficial, and in some cases may be more confusing than without.
In my current project, I've used "some" hungarian notation. It helped me make less logical mistakes, allowed me to extensively reuse variables rather than having to declare new ones each time to be safe, and saved me some time on having to look for variable declarations to read the accompanying note.
I doubt it's useful for everyone, but if you're having troubles with "messy variables" and don't have a naming "style"/"standard" of your own yet, it's definitely worth using Hungarian notation. Even if only temporary.
I doubt it's useful for everyone, but if you're having troubles with "messy variables" and don't have a naming "style"/"standard" of your own yet, it's definitely worth using Hungarian notation. Even if only temporary.
@Gaminic I will try Hungarian notation and then Camel Case. If I make less errors with Hungarian notation I'll use that.
@sohguanh Why do the standards change so much? I would prefer it if we all used C++.
@sohguanh Why do the standards change so much? I would prefer it if we all used C++.
Last edited on
You should all be aware that Hungarian Notation is different than other things like Camel Case (which, btw, is what Hungarian Notation uses as a base).
Things like Camel Case are only interested in how an identifier looks -- to increase its readability (supposedly).
Hungarian Notation is Camel Case, but with additional semantics added -- type information (in the common case) or value information (in the Apps version).
ThisIsCamelCase
iThisIsACamelCaseIntegerInHungarianNotation
usThisIsACamelCaseUnsafeStringInHungarianNotation
this_is_not_camel_case
Hope this helps.
[edit]Oh, the leading capitalization doesn't necessarily matter in Hungarian Notation, but it does make a difference whether you call it true Camel Case or not... I don't remember the other name right now...
Things like Camel Case are only interested in how an identifier looks -- to increase its readability (supposedly).
Hungarian Notation is Camel Case, but with additional semantics added -- type information (in the common case) or value information (in the Apps version).
ThisIsCamelCase
iThisIsACamelCaseIntegerInHungarianNotation
usThisIsACamelCaseUnsafeStringInHungarianNotation
this_is_not_camel_case
Hope this helps.
[edit]Oh, the leading capitalization doesn't necessarily matter in Hungarian Notation, but it does make a difference whether you call it true Camel Case or not... I don't remember the other name right now...
Last edited on
Variable names should denote the logical type of a variable. Like using i,j,k for indexes, but x,y,z for positions, and th, ph, rh for spherical coordinates. A difference might be called d.... A sum could be denoted by S... (or perhaps Σ... if you're using a language supporting unicode in variable names.)
Never use unicode characters in variable names. They're a pain to type, and can easily be misread in some fonts. Just stick to good old ascii. And don't write lowercase L's and 1's next to each other either.
Pages: 12