4 ms·

Please explain for the dummies: is this sort of naming convention just a fad that is out of style or has some of the latest advances in technology made it obsol

by listic 17y ago

Please explain for the dummies: is this sort of naming convention just a fad that is out of style or has some of the latest advances in technology made it obsolete?

deleted 17y ago
[deleted]
smanek 17y ago
Reasonably strong typing + better IDEs have made type-naming redundant. If you don't have both those two available, go ahead and use it though.
dchest 17y ago
It depends on language. In Delphi/Object Pascal the convention is/was to prefix classes with T or TProjectName. Because Pascal is case-insensitive language, classes are prefixed to avoid mixing them with variables (Cat = TCat.Create). In Objective C classes are usually prefixed with two capital letters (unique for company or project), like NSString. Because ObjC/C doesn't have namespaces, this serves the purpose of avoiding collisions with other classes that may have the same name. So yes, while it's a convention, it's here because there's no latest advances in technology to make it obsolete. In Ruby you don't have to prefix classes because there's a convention, enforced by language, to write class names in title case. In C#, the convention is not to prefix classes with letters, since it's case sensitive, has namespaces, and compiler takes care of type checking.
ajg1977 17y ago
Once upon a time a Hungarian chap named Simonyi invented a system of prefixing variables with letters to describe their type. This was actually a very good idea since at the time computer programs were rapidly growing in size and complexity, and developers did not have any of the fancy IDE features nor large high-resolution screens that we take for granted today. However as with many good ideas it was became taken to excess and and variables eventually became less readable - e.g. m_spszName would be a member variable, that is static, and is a pointer to a zero-terminated string. It did not help that people often disagreed the order of prefixes, or only used a subset of the full range. With the advent of better type-checking compilers and languages, intellisense IDE features, and screens that could display more than 80 lines Hungarian notation largely faded away. The 'C' prefix was originated (I think by MFC) to signify that a type was a class. Ironically it began around the time that strict Hungarian notation began to fade out, and classes became liberally used in code. There are still many good reasons to use certain prefix's on your variable ('m' for member being the most widely used) but things like CFoo or pszName are largely antiquated relics of a past time. It just gave me a little chuckle when I saw it :)
olavk 17y ago
Hungarian notation was (if I recall correctly) invented for use in BCPL which was a language which had only one type, the 16 bit integer, which was used for both pointers and any other type of data. It is pretty important to avoid e.g. treating a boolean as a pointer, but since the language itself didn't offer any way to distinguish between these types, it was proposed to encode type info in the variable names. So pointer variables was prefixed with ptr, booleans with b and so on. That way the developers could perform manual type-safety checks when they read and wrote code. Modern type systems have of course made that obsolete.
cdr 17y ago
Ignore the Hungarian haters. Joel's stance on Hungarian notation is laid out here: http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html
- ankp 17y ago
  Ignore the Hungarian haters. Which would be basically everyone who didn't learn to write software on Windows. If you have a reasonable type system and language, leverage it to enforce semantics that Spolsky suggests you use Hungarian notation to imply by convention. You'll be much less likely to be castigated by the individual who has to maintain your code after you. Microsoft has put Hungarian notation to rest, nobody else o speak of uses it, and you shouldn't either.
  - deleted 17y ago
    [deleted]
  - cdr 17y ago
    The type of Hungarian notation Spolsky uses at Fog Creek is different than the Hungarian once pushed by Microsoft. He goes over that in the linked article. I'm not defending it - I've never tried it - but it obviously works for Joel. Also, if you're working at Fog Creek, the guy who has to maintain your code after you will also be using Hungarian.
    - ankp 17y ago
      The type of Hungarian notation Spolsky uses at Fog Creek is different than the Hungarian once pushed by Microsoft. Hungarian notiation (of any variety) started (and ended) at Microsoft. Also, if you're working at Fog Creek, the guy who has to maintain your code after you will also be using Hungarian. If you're working at Fog Creek you're writing code in a custom in-house programming language as well as using Hungarian notation. I don't think the example is generally useful or applicable to anyone else.
- erlanger 17y ago
  That's a terrible defense. Only a cat, and a fairly new one to coding at that, would find Hungarian notation to be useful as a debugging tool.

by listic 17y ago

Please explain for the dummies: is this sort of naming convention just a fad that is out of style or has some of the latest advances in technology made it obsolete?

deleted 17y ago

[deleted]

smanek 17y ago

Reasonably strong typing + better IDEs have made type-naming redundant. If you don't have both those two available, go ahead and use it though.

dchest 17y ago

It depends on language. In Delphi/Object Pascal the convention is/was to prefix classes with T or TProjectName. Because Pascal is case-insensitive language, classes are prefixed to avoid mixing them with variables (Cat = TCat.Create). In Objective C classes are usually prefixed with two capital letters (unique for company or project), like NSString. Because ObjC/C doesn't have namespaces, this serves the purpose of avoiding collisions with other classes that may have the same name. So yes, while it's a convention, it's here because there's no latest advances in technology to make it obsolete. In Ruby you don't have to prefix classes because there's a convention, enforced by language, to write class names in title case. In C#, the convention is not to prefix classes with letters, since it's case sensitive, has namespaces, and compiler takes care of type checking.

ajg1977 17y ago

Once upon a time a Hungarian chap named Simonyi invented a system of prefixing variables with letters to describe their type. This was actually a very good idea since at the time computer programs were rapidly growing in size and complexity, and developers did not have any of the fancy IDE features nor large high-resolution screens that we take for granted today. However as with many good ideas it was became taken to excess and and variables eventually became less readable - e.g. m_spszName would be a member variable, that is static, and is a pointer to a zero-terminated string. It did not help that people often disagreed the order of prefixes, or only used a subset of the full range. With the advent of better type-checking compilers and languages, intellisense IDE features, and screens that could display more than 80 lines Hungarian notation largely faded away. The 'C' prefix was originated (I think by MFC) to signify that a type was a class. Ironically it began around the time that strict Hungarian notation began to fade out, and classes became liberally used in code. There are still many good reasons to use certain prefix's on your variable ('m' for member being the most widely used) but things like CFoo or pszName are largely antiquated relics of a past time. It just gave me a little chuckle when I saw it :)

olavk 17y ago

Hungarian notation was (if I recall correctly) invented for use in BCPL which was a language which had only one type, the 16 bit integer, which was used for both pointers and any other type of data. It is pretty important to avoid e.g. treating a boolean as a pointer, but since the language itself didn't offer any way to distinguish between these types, it was proposed to encode type info in the variable names. So pointer variables was prefixed with ptr, booleans with b and so on. That way the developers could perform manual type-safety checks when they read and wrote code. Modern type systems have of course made that obsolete.

cdr 17y ago

Ignore the Hungarian haters. Joel's stance on Hungarian notation is laid out here: http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html

ankp 17y ago
Ignore the Hungarian haters. Which would be basically everyone who didn't learn to write software on Windows. If you have a reasonable type system and language, leverage it to enforce semantics that Spolsky suggests you use Hungarian notation to imply by convention. You'll be much less likely to be castigated by the individual who has to maintain your code after you. Microsoft has put Hungarian notation to rest, nobody else o speak of uses it, and you shouldn't either.
- deleted 17y ago
  [deleted]
- cdr 17y ago
  The type of Hungarian notation Spolsky uses at Fog Creek is different than the Hungarian once pushed by Microsoft. He goes over that in the linked article. I'm not defending it - I've never tried it - but it obviously works for Joel. Also, if you're working at Fog Creek, the guy who has to maintain your code after you will also be using Hungarian.
  - ankp 17y ago
    The type of Hungarian notation Spolsky uses at Fog Creek is different than the Hungarian once pushed by Microsoft. Hungarian notiation (of any variety) started (and ended) at Microsoft. Also, if you're working at Fog Creek, the guy who has to maintain your code after you will also be using Hungarian. If you're working at Fog Creek you're writing code in a custom in-house programming language as well as using Hungarian notation. I don't think the example is generally useful or applicable to anyone else.
erlanger 17y ago
That's a terrible defense. Only a cat, and a fairly new one to coding at that, would find Hungarian notation to be useful as a debugging tool.