4 ms·

Hungarian Notation is not, and was never, for representing the type of a variable. It's about usage of that variable. "c" represents a change, "w" means width,

by krallja 10y ago

Hungarian Notation is not, and was never, for representing the type of a variable. It's about usage of that variable. "c" represents a change, "w" means width, "x" means horizontal position, "ix" is an index into an array. All of them are `int`s, but "cw" "cx" "ix" and "x" are all different kinds of variables. http://www.joelonsoftware.com/articles/Wrong.html http://www.joelonsoftware.com/articles/Wrong.html

icebraining 10y ago
Some would say those should be their own types, even if simply aliases to built-in ones.
- krallja 10y ago
  I strongly agree, but nobody* uses languages that would make it a compilation error to add "cw" and "ix" together.
  - wvenable 10y ago
    True. But for documentation purposes it makes more sense than tacking on prefixes to names.
  - geofft 10y ago
    Nobody uses C? https://github.com/torvalds/linux/blob/v4.3/arch/alpha/include/asm/page.h#L26-L33 https://github.com/torvalds/linux/blob/v4.3/arch/alpha/inclu... Or C++? http://www.boost.org/doc/libs/1_60_0/libs/serialization/doc/strong_typedef.html http://www.boost.org/doc/libs/1_60_0/libs/serialization/doc/... (I'd buy "Nobody uses Rust", but I can't resist a "maybe they should.")
michaelfeathers 10y ago
de jure != de facto In practice it was used far more for type.
wvenable 10y ago
Still a terrible idea. I agree with the poster below that these should just be their own types.
Kristine1975 10y ago
There are two kinds of Hungarian Notation: Systems and Apps Hungarian: https://en.wikipedia.org/wiki/Hungarian_notation https://en.wikipedia.org/wiki/Hungarian_notation In Systems Hungarian notation, the prefix encodes the actual data type of the variable. Apps Hungarian notation strives to encode the logical data type rather than the physical data type; in this way, it gives a hint as to what the variable's purpose is, or what it represents.
shmageggy 10y ago
Whoa. I finally understand Panda's usage of .ix() for accessing elements of a data frame. I always assumed it was a goofy shorthand for "IndeX". http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.ix.html http://pandas.pydata.org/pandas-docs/stable/generated/pandas...

by krallja 10y ago

icebraining 10y ago

Some would say those should be their own types, even if simply aliases to built-in ones.

krallja 10y ago
I strongly agree, but nobody* uses languages that would make it a compilation error to add "cw" and "ix" together.
- wvenable 10y ago
  True. But for documentation purposes it makes more sense than tacking on prefixes to names.
- geofft 10y ago
  Nobody uses C? https://github.com/torvalds/linux/blob/v4.3/arch/alpha/include/asm/page.h#L26-L33 https://github.com/torvalds/linux/blob/v4.3/arch/alpha/inclu... Or C++? http://www.boost.org/doc/libs/1_60_0/libs/serialization/doc/strong_typedef.html http://www.boost.org/doc/libs/1_60_0/libs/serialization/doc/... (I'd buy "Nobody uses Rust", but I can't resist a "maybe they should.")

michaelfeathers 10y ago

de jure != de facto In practice it was used far more for type.

wvenable 10y ago

Still a terrible idea. I agree with the poster below that these should just be their own types.

Kristine1975 10y ago

There are two kinds of Hungarian Notation: Systems and Apps Hungarian: https://en.wikipedia.org/wiki/Hungarian_notation https://en.wikipedia.org/wiki/Hungarian_notation In Systems Hungarian notation, the prefix encodes the actual data type of the variable. Apps Hungarian notation strives to encode the logical data type rather than the physical data type; in this way, it gives a hint as to what the variable's purpose is, or what it represents.

shmageggy 10y ago

Whoa. I finally understand Panda's usage of .ix() for accessing elements of a data frame. I always assumed it was a goofy shorthand for "IndeX". http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.ix.html http://pandas.pydata.org/pandas-docs/stable/generated/pandas...