Hungarian notation in C# [duplicate]

Answer 1

Hungarian notation found its first major use with the BCPL programming language. BCPL is short for Before C Programming Language and is an ancient (designed in 1966), typeless language where everything is a word. In that situation, Hungarian notation can help with naked-eye type-checking.

Many years have passed since then...

Here's what the latest Linux kernel documentation says (bold mine):

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer.

Please also note that there are two types of Hungarian notation:

• Systems Hungarian notation: The prefix encodes physical data type.

• Apps Hungarian notation: The prefix encodes logical data type.

Systems Hungarian notation is no longer recommended due to type-checking redundancy which is in turn due to advancement in compiler capabilities. However, you may still use Apps Hungarian notation if the compiler doesn't check logical data types for you. As a rule of thumb, Hungarian notation is good if and only if it describes semantics that are not available otherwise.

Answer 2

If Hungarian notation is deep in your and your team's and your company's heart, by all means use it. It is no longer considered a best practice as far as I can read from blogs and books.

Answer 3

I don't care, I always use a combination of Hungarian and Pascal/Camel Case.

Not for data types, but for controls. Because txtName is pretty self-explanatory. Some people will name it NameTextBox which is too long. lblAge, txtName, rdoTrue, cboCities, lstAccountInfo. Nice and quick and compact For variables, it's Pascal case for ordinary variables and properties. "firstName = txtFName.Text" (seriously if you can't look at that and realize it's a textbox, sheez). Then I'll use Camel Case for methods

public void PrintNames (string fName, string lName)
{
    lblFullName.Text=fName + " " + lName;
}

So yes, I use Hungarian case, so sue me. No one can say they don't know what those variables are and I like being able to see really quickly without having to hover over what type of variable or control it is. When I first started programming I used all caps for every variable so this is a step up. And for pity's sake, do NOT put the opening curly brace at the end of the line. Nice and symmetrical.

Answer 4

Joel Spolsky has a really good article on this topic. The quick summary is that there's two types of Hungarian notation that are used in practice.

The first is "Systems Hungarian" where you specify the variable type using a prefix. Things like "str" for string. This is nearly useless information, especially since modern IDEs will tell you the type anyway.

The second is "Apps Hungarian" where you specify the purpose of the variable with a prefix. The most common example of this is using "m_" to indicate member variables. This can be extremely useful when done correctly.

My recommendation would be to avoid "Systems Hungarian" like the plague but definitely use "Apps Hungarian" where it makes sense to. I suggest reading Joel's article. It's a bit long winded but explains it much better than I could.

The most interesting part of this article is that the original inventor of Hungarian notation, Charles Simonyi, created "Apps Hungarian" but his paper was horribly misinterpreted and the abomination of "Systems Hungarian" was created as a result.

Answer 5

Hungarian notation is a terrible mistake, in any language. You shouldn't use it in C++ either. Name your variables so you know what they're for. Don't name them to duplicate type information that the IDE can give you anyway, and which may change (and is usually irrelevant anyway. If you know that something is a counter, then it doesn't matter whether it's an int16, 32 or 64. You know that it acts as a counter, and as such, any operation that's valid on a counter should be valid. Same argument for X/Y coordinates. They're coordinates. It doesn't matter if they're floats or doubles. It may be relevant to know whether a value is in units of weight, distance or speed. It doesn't matter that it's a float.).

In fact, Hungarian notation only came around as a misunderstanding. The inventor had intended for it to be used to describe the "conceptual" type of a variable (is it a coordinate, an index, a counter, a window?)

And the people who read his description assumed that by "type" he meant the actual programming language type (int, float, zero-terminated string, char pointer)

That was never the intention, and it is a horrible idea. It duplicates information that the IDE can better provide, and which isn't all that relevant in the first place, as it encourages you to program at the lowest possible level of abstraction.

So why? Am I the only person that has m_strExePath or m_iNumber in my C# code?

No. Unfortunately not. Tell me, what would exePath be if it wasn't a string? Why do I, as a reader of your code, need to know that it is a string? Isn't it enough to know that it is the path to the executable? m_iNumber is just badly named. which number is this? WHat is it for? You have just told me twice that it is a number, but I still don't know what the meaning of the number is.

Answer 6

No, you're not the only one who does it. It's just generally accepted that Hungarian notation isn't the best way to name things in C# (the IDE handles a lot o the issues that Hungarian notation tried to address).