Are variable prefixes (“Hungarian notation”) reall

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 6 years ago.

Since C# is strongly typed, do we really need to prefix variables anymore?

e.g.

iUserAge
iCounter
strUsername

I used to prefix in the past, but going forward I don't see any benefit.

Answer 1

Most of the arguments I see against Hungarian notation mention that modern editors and IDEs are perfectly capable of giving you all the information you need to know about every identifier. Fair enough.

But what about printed code? Don't you carry out code reviews or walkthroughs on paper? Don't you use printed code for training purposes? Don't you use code snippets for online help? Hungarian notation is extremely valuable in these occasions.

I keep using (some sort of) Hungarian notation in all my code. I find its absence ugly and lacking in information.

Answer 2

Even though the compiler can quickly and easily check the type of a variable, humans are unable to do so while skimming a piece of source code. Therefore some people (like me) prefer to make variable names a tad more verbose, making them quickly recognizable to be global or class variables, string or int, etc.

It might not help the compiler, but when reading a foreign piece of code, it surely saves you having to look up each variable manually...

Answer 3

The only places I see fit to bend the standards and prefix variables:

• control names: txtWhatever - and I see I'm not the only one. The nice thing is that you can come up with stuff like lblName next to txtName, and you don't need to go into the NameLabel/NameTextBox direction.

• class member variables: _whatever. I've tried both m_ and no prefix at all and ended up with simple underscore. m_ is more difficult to type and having no prefix becomes confusing sometimes (especially during maintenance, I know all of you know their code by heart while writing it)

I didn't find any consistent situation where prefixing a variable with its type would make the code more readable, though.

EDIT: I did read the Microsoft guidelines. However I consider that coding styles are allowed to evolve and/or be "bent", where appropriate. As I mentioned above, I found using underscore prefix useful by trial and error, and is certainly better than using this.whatever everywhere in the code.

Supporting the "evolving" theory - back in .NET 1.x when Microsoft released coding guidelines, they advised using Camel casing for everything, even constants. I see now they've changed and advise using Pascal case for constant or public readonly fields.

Furthermore, even .NET Framework class library is currently full of m_ and _ and s_ (try browsing the implementation with the Reflector). So after all, it's up to the developer, as long as consistency is preserved across your project.

Answer 4

The only prefix I would consider for C# is a _ for member variables such as

public class Test
{
    private int _id;
}

Answer 5

Inside the code and when working with data types I see no reason for the use of Hungarian notation.

But when I'm working with a series of user interface control, be that they are textboxes, dropdown lists, grids or what not, I like to have my intellisense work for me. So to accomplish that, I usually make the id of the control with a prefix of "uxSomeControlName". This way, when I'm looking for that textbox to grab it's text value, all I have to do is type "ux" and all of the user interface ID's are displayed. No need to search for txt, ddl, grd, or anything else.

Now is this correct, if you read the above, no. But I don't want to sit hear and try to remember a dozen or more control names when I just have to know two letters.

Like I said, this is only when working on the front end.

Answer 6

While many programmers today are abandoning it, I would still use it in certain cases. Here are some of them;

• If you are maintaining code that already uses it, then I would keep using it.

• When your company style guidelines still require or even suggest it.

• When your documentation has a simple alphanumerically sorted list of variables, it helps group like types.