Comment by Silhouette | Hacker News Reader

Comment by Silhouette | Hacker News Reader

Parent Full thread

Yes, that's more-or-less correct.

The prefix wouldn't necessarily be only a single character. For example, using a "p" prefix for pointer values was a common convention in Microsoft ecosystem projects where Hungarian notation was probably most popular. Thus a pointer-to-char (char*) parameter might be prefixed with "pc".

But yes, the fundamental idea was to convey information about the type of the variable as part of its name. That convention has mostly died out today, probably due to a combination of IDEs being used routinely in the ecosystem where the notation was most popular, and more recently due to modern languages having better type systems that enforce the rules objectively instead of relying on a convention.

Ironically, with the popularity of dynamically typed languages today, we sometimes seem to have regressed to a point where interfaces to functions aren't always clear, and lots of avoidable bugs creep in due to passing incorrect types of data around. The emphasis on rapid evolution and ad-hoc/organic design we see with a lot of "agile" development processes isn't always helpful either. Put those together, and you almost have the complete opposite of the systematic design and robust processes advocated in the slides here.

> But yes, the fundamental idea was to convey information about the type of the variable as part of its name.

No.

There are two types of Hungarian Notation.

The original one ("apps hungarian"), which made sense and sometimes still makes sense. Here you would assign a meaning to a prefix. For example, if you're writing MS Word a variable named "sWidth" might be the width of something in pixels on the screen (s), while "pWidth" might be the same width, but in logical units (say pt) on the page. Then you could have a function ptos, and it's easy to see whether variables were used correctly in computations - you can't mix screen-space and page-space coordinates without conversion.

This made a lot of sense, because either variable would likely just be an "int".

Similarly in a Python Webapp one might write "us_name" where us means UnSanitized. So before passing that anywhere else you know you need to sanitize it. See a "us_" variable somewhere that isn't a call to a sanitizer? Probably a bug!

Then there's that other one, "system hungarian", which is the stupid thing everyone knows with stuff like lpcstrWindowName.

Actually it would be something like cxPixels and cxPoints with c meaning "count", x meaning "horizontal" and Pixels/Point being the actual unit. You can see several Windows structs having this naming convention (the simplest one being SIZE which simply contains cx and cy).

EDIT: people often see these as prefixes, but they are not really prefixes, the original paper was about the whole name.

All of your examples are still type information. They are more specific than the types provided by a basic C-style type system, but that's the point.

We can easily distinguish between the two by calling them units.

It's not necessarily just units, though that's one useful example. Types could also include things like whether a text string has been escaped in a certain way, whether data has come from a trusted or untrusted source, and countless other reasons you might want to ensure you don't use a value with a certain property in the wrong way.

In modern languages where defining custom types and enforcing their use is easier, there is less need to distinguish these properties by convention. Twenty years ago, when we were doing more development with languages in the C family that don't have very powerful systems, it was a different story, and so naming conventions went some way to helping keep track of what data you were really passing around beyond just "It's an int" and the like.

All true, but if we say "type" then the default assumption will be "int", "string" etc. -- "pixels" and "millimeters on a piece of paper" are the same type then.

This is, after all, exactly how systems hungarian misunderstanding came about.

I would also add that even in modern C++ it's possible to have the compiler check your usage of page and screen widths by creating separate types, ScreenWidth and PageWidth. You would then generate compiler errors on assignment, or provide single-argument constructors for implicit conversion.

It's just that nobody ever actually does that in C++.

The people that want to do this just use Haskell :)

Reply on news.ycombinator.com