Are variable prefixes (“Hungarian notation”) really necessary anymore? [closed]

Question

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

Are variable prefixes ( Hungarian ) really necessary anymore?

NO!

In fact, Microsoft's own style guidelines (where the practice originated) now recommend against it. In particular, see the section on General Naming Conventions, which includes the following text (in bold type, no less):

Do not use Hungarian notation.

Of course, these guidelines are not binding or mandatory outside of Microsoft. However, this is the published recommendation of the platform vendor, and it goes beyond merely removing the positive recommendation from any prior guide, to instead a strongly-worded and emphasized negative recommendation today.

In other words, don't use them anymore.

Answer 2

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.