4 ms·

I used to have much disgust for hungarian notation. When I worked on my first big C++ codebase though, hungarian notation was standard, and I have to say, it ma

by MAGZine 12y ago

I used to have much disgust for hungarian notation. When I worked on my first big C++ codebase though, hungarian notation was standard, and I have to say, it made the code more readable. using 's' for static, 'm' for member, etc brought some extra clarity as to what was happening. It's not that we couldn't determine these thing for ourselves (VS has great code-crawling facilities), but its less time hovering, symbol searching, and jumping-to-declaration. I don't use it out of choice, but it isn't so bad. Though, this was using a slightly HN slightly differently. complete variable types in the name i have different feelings for!

stormbrew 12y ago
There's a limited degree to which it's useful in resolving scope and type ambiguities in C or C++, but excessive use could definitely render things much less readable. It doesn't help that some of those letters survived long past their shelf life (ie. 'lp' for long pointer, where in non-segmented architectures there is no far (aka long) and near pointer distinction). These days in C++ I'd only ever consider using s or g, and never the type specifiers. I also largely consider signalling member variable vs. local variable to be pointless in all its forms (including _ suffix or prefix) now.
darklajid 12y ago
I think you're mixing two absolutely different types of Hungarian Notation. No offense, but what you describe seems more or less like the reviled version (stuffing ~redundant~ information in the name, where you end up with strName and iCounter). The more-or-less accepted version described in the GP is trying to fix a shortcoming of the language's type system. If you cannot tell your compiler that this is a (default example) pixel value and this is a color, because both are plain ints to it, you're trying to make accidents less likely by requiring the programmer to double-check the prefixes (which encode a subtype, a special type. Not int, but int-representing-color or int-as-a-bool-here).
- Ntrails 12y ago
  iCounter always makes me wonder why someone would be iterating through counters! I've still got the: for iObject = 1:nObject style from matlab coding firmly rooted in my head - when hungarian isn't even creating universally and easily understood/parsed names I just can't see the value.
reacweb 12y ago
I have no strong opinion about hungarian notation, but I have noticed that hungarian notation haters were often english native speakers.
- reacweb 12y ago
  Please, stop mod me down ! In my work, I have to work with developers from many countries. Understanding cultural differences is very important when many nationalities are involved. There was nothing pejorative in this one.
  - isaacremuant 12y ago
    IMHO, You're not contributing just offering anecdotal evidence that could easily be construed as an unsupported attack. For instance, I'm not a native English speaker and I don't see the use of Hungarian notation (specially when used heavily). There's a difference between a couple of handy conventions and things that actually make your code hard to read and less flexible (change the type, change the name too).
    - chipsy 12y ago
      I'll contribute something I noticed, as a native English speaker, when I started defaulting to too-terse in my own style: Instead of spending time worrying about how to capture enough meaning in a concise name, I can write "km", write a comment beside the declaration like "keyboard mapping", and I'm done. The symbol-meaning is mnemonic, the documentation is verbose. Or to consider it another way, we've constructed the idea of variable naming being essential under the premise that we want code to relate to native language at each step. But when code is put into an interlingual context this breaks down relatively quickly - at the extreme end, the non-native speaker has to reverse-engineer meanings anyway. In the terse/documented style, I more explicitly acknowledge this separation of actions and definitions. A lot of the thinking around naming conventions feeds into the expected workflow - when considering the pre-Intellisense, namespace-free era of C coding that Windows Hungarian arose in, it makes sense to bulk up the names a little so that every point of the code conveys more meaning and doesn't collide by accident. But if the environment already gives you ample guidance towards meaning and categorization, the bottleneck revolves more around how much code fits onscreen.
hnal943 12y ago
Joel tells a pretty compelling story about two types of Hungarian notation: http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html
- Thrall 12y ago
  From that article: "used in my example above where we decided that us meant “unsafe string” and s meant “safe string.” They’re both of type string. The compiler won’t help you if you assign one to the other" Assuming you have the luxury of a language with a good type system (either because it's designed for the task in hand or it's extensible), the compiler can help you, and you would be much better off having unsafe and safe strings as separate types. Then the encode function simply becomes a function of type unsafe -> safe. I believe Michael Snoymann touches on this in his presentation, "Designing Type-Safe Haskell APIs"[1]. I'm not arguing that Joel's method isn't a good idea. However, if you can it's better to leave hints for the compiler, not just the programmers. [1] https://docs.google.com/presentation/d/1K7smIeqmca-fY8qgQUKrvWWHTUPJoKuVLRtLeWYFMtI/edit#slide=id.gdee14bb_0_5 https://docs.google.com/presentation/d/1K7smIeqmca-fY8qgQUKr...
amaks 12y ago
's' for static, 'm' for member is not a Hungarian notation. It's just an established prefix patterns. Some style guides use '_' as a suffix for class member variables, and g_ prefix for globals. It's just a consistency. Hungarian notation is a nightmarish replacement of the intellisense such as lpszFoo.
shmerl 12y ago
Out of that I use m_ for members. But that's about it. It is very helpful when you read lengthy methods code. For actual names I use snake notation. I.e. something like int m_some_property; Type in the name is definitely an overkill.
- danielki 12y ago
  Type in the name is overkill for int or char, but it's useful when you've got multiple levels of pointers. ppszName is a pointer to a pointer to a null-terminated string, whereas pbFoo is a pointer to a byte-array. Both of these are void, but what* they point to is important. Additionally, you can have the pairing of pbFoo with pcbFoo, where pbFoo is a byte array, and pcbFoo is a pointer to the size of pbFoo.
  - shmerl 12y ago
    All of that can be checked in definition. So there is no need to do that but it can be convenient sometimes. It's a question of balancing how much redundant information you want to put in the name to save looking up the definition. If you deal with some pointer however you better look at definition anyway unless you want to risk getting in trouble, so there is no need to put any of that in the name. Void pointers are a major mess which should be avoided altogether unless there is really no other choice. And putting anything in the name of the void pointer doesn't really prevent it from pointing to something else entirely.

by MAGZine 12y ago

stormbrew 12y ago

There's a limited degree to which it's useful in resolving scope and type ambiguities in C or C++, but excessive use could definitely render things much less readable. It doesn't help that some of those letters survived long past their shelf life (ie. 'lp' for long pointer, where in non-segmented architectures there is no far (aka long) and near pointer distinction). These days in C++ I'd only ever consider using s or g, and never the type specifiers. I also largely consider signalling member variable vs. local variable to be pointless in all its forms (including _ suffix or prefix) now.

darklajid 12y ago

I think you're mixing two absolutely different types of Hungarian Notation. No offense, but what you describe seems more or less like the reviled version (stuffing ~redundant~ information in the name, where you end up with strName and iCounter). The more-or-less accepted version described in the GP is trying to fix a shortcoming of the language's type system. If you cannot tell your compiler that this is a (default example) pixel value and this is a color, because both are plain ints to it, you're trying to make accidents less likely by requiring the programmer to double-check the prefixes (which encode a subtype, a special type. Not int, but int-representing-color or int-as-a-bool-here).

Ntrails 12y ago
iCounter always makes me wonder why someone would be iterating through counters! I've still got the: for iObject = 1:nObject style from matlab coding firmly rooted in my head - when hungarian isn't even creating universally and easily understood/parsed names I just can't see the value.

reacweb 12y ago

I have no strong opinion about hungarian notation, but I have noticed that hungarian notation haters were often english native speakers.

reacweb 12y ago
Please, stop mod me down ! In my work, I have to work with developers from many countries. Understanding cultural differences is very important when many nationalities are involved. There was nothing pejorative in this one.
- isaacremuant 12y ago
  IMHO, You're not contributing just offering anecdotal evidence that could easily be construed as an unsupported attack. For instance, I'm not a native English speaker and I don't see the use of Hungarian notation (specially when used heavily). There's a difference between a couple of handy conventions and things that actually make your code hard to read and less flexible (change the type, change the name too).
  - chipsy 12y ago
    I'll contribute something I noticed, as a native English speaker, when I started defaulting to too-terse in my own style: Instead of spending time worrying about how to capture enough meaning in a concise name, I can write "km", write a comment beside the declaration like "keyboard mapping", and I'm done. The symbol-meaning is mnemonic, the documentation is verbose. Or to consider it another way, we've constructed the idea of variable naming being essential under the premise that we want code to relate to native language at each step. But when code is put into an interlingual context this breaks down relatively quickly - at the extreme end, the non-native speaker has to reverse-engineer meanings anyway. In the terse/documented style, I more explicitly acknowledge this separation of actions and definitions. A lot of the thinking around naming conventions feeds into the expected workflow - when considering the pre-Intellisense, namespace-free era of C coding that Windows Hungarian arose in, it makes sense to bulk up the names a little so that every point of the code conveys more meaning and doesn't collide by accident. But if the environment already gives you ample guidance towards meaning and categorization, the bottleneck revolves more around how much code fits onscreen.

hnal943 12y ago

Joel tells a pretty compelling story about two types of Hungarian notation: http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html

Thrall 12y ago
From that article: "used in my example above where we decided that us meant “unsafe string” and s meant “safe string.” They’re both of type string. The compiler won’t help you if you assign one to the other" Assuming you have the luxury of a language with a good type system (either because it's designed for the task in hand or it's extensible), the compiler can help you, and you would be much better off having unsafe and safe strings as separate types. Then the encode function simply becomes a function of type unsafe -> safe. I believe Michael Snoymann touches on this in his presentation, "Designing Type-Safe Haskell APIs"[1]. I'm not arguing that Joel's method isn't a good idea. However, if you can it's better to leave hints for the compiler, not just the programmers. [1] https://docs.google.com/presentation/d/1K7smIeqmca-fY8qgQUKrvWWHTUPJoKuVLRtLeWYFMtI/edit#slide=id.gdee14bb_0_5 https://docs.google.com/presentation/d/1K7smIeqmca-fY8qgQUKr...

amaks 12y ago

's' for static, 'm' for member is not a Hungarian notation. It's just an established prefix patterns. Some style guides use '_' as a suffix for class member variables, and g_ prefix for globals. It's just a consistency. Hungarian notation is a nightmarish replacement of the intellisense such as lpszFoo.

shmerl 12y ago

Out of that I use m_ for members. But that's about it. It is very helpful when you read lengthy methods code. For actual names I use snake notation. I.e. something like int m_some_property; Type in the name is definitely an overkill.

danielki 12y ago
Type in the name is overkill for int or char, but it's useful when you've got multiple levels of pointers. ppszName is a pointer to a pointer to a null-terminated string, whereas pbFoo is a pointer to a byte-array. Both of these are void, but what* they point to is important. Additionally, you can have the pairing of pbFoo with pcbFoo, where pbFoo is a byte array, and pcbFoo is a pointer to the size of pbFoo.
- shmerl 12y ago
  All of that can be checked in definition. So there is no need to do that but it can be convenient sometimes. It's a question of balancing how much redundant information you want to put in the name to save looking up the definition. If you deal with some pointer however you better look at definition anyway unless you want to risk getting in trouble, so there is no need to put any of that in the name. Void pointers are a major mess which should be avoided altogether unless there is really no other choice. And putting anything in the name of the void pointer doesn't really prevent it from pointing to something else entirely.