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.
If this question can be reworded to fit the rules in the help center, please edit the question.

29 Answers
29

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):

To be fair though, the MS style guidelines are arbitrary for large parts and thus not a useful point of reference.
–
Konrad RudolphNov 21 '08 at 20:38

@Konrad, because something is arbitrary doesn't mean they aren't useful. Sometimes simply having a standard in and of itself is useful. Having something consistent is powerful. Hungarian is, arguably, not consistent. Checkbox? cb? cbox? ckb? This is why I fight against it.
–
NazadusMar 13 '09 at 13:55

2

Since when is some guideline-writer in MS the last word? Sure standards are good, but not when they are set in concrete. Just today I was writing iaWhichDose because I wanted something that clearly said it was an integer array of "which dose" indexes, and iCat which clearly says it is the index of a category. The name tells me what it means, without getting really verbose. What on earth is accomplished by disallowing that?
–
Mike DunlaveyFeb 25 '10 at 23:23

@Mike - Where did you get "set in concrete/disallowed" from "[not] really necessary any more/recommend against it"?
–
Joel CoehoornFeb 26 '10 at 0:04

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.

I've found this to be very useful. The func param prefixes in particular are useful. Way down inside a function you can always tell where that var came from at a glance. And typically we will copy the var to another when we want to modify it or change its meaning.

So in short: prefixes for types are unnecessary with modern tools. The IDE takes care of identifying and checking that stuff for you. But scope-based prefixes are very useful for readability and clarity.

There are also fun side benefits like with Intellisense. You can type i_ ctrl-space and get all the input params to the func to choose from. Or g_ ctrl-space to get all your singletons. It's a time-saver.

I wish I could vote this p twice. The usefulness of this for readability is worth one, plus one for the intellisense trick!
–
MighMoSJul 24 '09 at 23:23

This is my favorite convention, although I don't distinguish between the input/output parameters.
–
M. DudleyJan 25 '11 at 18:04

Agree completely: type prefixes: no; scope prefixes: yes. (although I use a different set). It has the additional benefit of avoiding naming conflicts; (ie: a field, parameter, and local can all share the same 'name' without having to get overly creative: var arg = argument; Argument = argument; VS var agument = pArgument; mArgument = pArgument;).
–
SahuaginMar 29 '12 at 23:34

Hungarian notation is ugly. The only exception is with interfaces, where most people think it's acceptable.

Linus sums it up well:
"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"

Yes, if Hungarian notation were used as it was originally meant, instead of as implemented by Microsoft. Much like the example above, which shows text boxes and corresponding labels as lblWhatever, txtWhatever. Use it to define the use of the variable, not the type. It can provide information to know that your number is moneyTotal, which tells me more than just the data type.

IMHO, Java would be a vastly better language if Hungarian notation were used as it was originally meant. If a field has type int[], it will often be very important to know whether whether other references may exist to that same array, and whether the contents of that array may ever change. Nothing in Java's type system says anything about either of those things, but including such information within names could make a many kinds of of mistakes much more obvious.
–
supercatFeb 14 '14 at 0:11

Prefixes are a leftover from the VB (and older!) days when Hungarian Notation was king. That is no longer the case, though the C# community does mandate things like using a prefix of Capital I for interfaces (e.g. ILoadable).

Hungarian notation is no longer needed to identify data types like in your string example, but it still can be useful for identifying characteristics of variables in other ways. Here's a good article that talks about useful ways of using the Hungarian notation: http://www.joelonsoftware.com/articles/Wrong.html

Here's an excerpt

"In Simonyi’s version of Hungarian notation, every variable was prefixed with a lower case tag that indicated the kind of thing that the variable contained.

For example, if the variable name is rwCol, rw is the prefix.

I’m using the word kind on purpose, there, because Simonyi mistakenly used the word type in his paper, and generations of programmers misunderstood what he meant."

He also uses an example of identifying strings prefixed with an 's' or a 'u' to identify if they are secure to print out or not, so that a statement like print(uSomeString); can easily be identified as wrong.

I personally don't anymore, however you will still people argue to prefix for scope.

I go with Microsoft and use their Capitalization Styles for all naming conventions. The entire "Design Guidelines for Class Library Developers" section, which that link is a part of, is pure gold, in my opinion.

Additionally, I love the "Framework Design Guidelines" book from Addison Wesley. It covers all of these guidelines with annotations from Microsoft team members on to why they recommend what they are proposing and how it is adopted within the organization.

Well, to counter, I'd say - it depends. I'm personally against them, but it comes down to your team. Each team should be responsible for developing their own set of guidelines. Hopefully that doesn't include so-called Hungarian Notation, but it really should be a team decision. You might find cases where you want to break with the style guidelines.

I am all for collaborative team decisions, but I cannot agree that the team should choose to use outdated standards for comfort. Honestly, it does not foster development of skills to do things a certain way because it "has always been done like that". Just adding a counter to your counter. :-)
–
joseph.ferrisNov 21 '08 at 16:13

2

I agree with your counter, and raise you this counter. You shouldn't change just for change's sake either. There may be a very important reason those are named a certain way. So figure out that reason, and either stick to it, or rename them. Just make it a team decision. :)
–
Cory FoyNov 23 '08 at 2:22

What makes me curious about this question is the fact that the languages (C then C++) where prefixing (i.e., Hungarian notation) was introduced were also strongly-typed. For all I know, it was done with Pascal's use at Microsoft as well. And it would seem that it was also used with Mesa, a strongly-typed language that the Hungarian may have had some familiarity with [;<).

That being the case, it is fair to get beneath the question and consider (1) what problem was prefixing used to help solve and (2) how has that problem gone away?

I know that's not exactly an answer, but it might be more useful than the blanket objections to use of prefixes as outmoded or wrong-headed.

What's even more ironic is that I've never seen Hungarian notation used in the spot where I'd consider it most important: distinguishing whether a field of a mutable reference type (e.g. int[]) holds the only reference to a safely-mutable object, or a possibly-shared reference to an object that--even though it's of a mutable type--must never be mutated. The distinction is extremely important, and IMHO Java and C# would be better languages if they encouraged the use of Hungarian notation to distinguish between the different "kinds" of references.
–
supercatFeb 20 at 21:24

Definitely not. As a general rule, I've come to believe that it's just noise. If you're an indepedent consultant or your company doesn't have a comprehensive style guide, IDesign has a great guide. Just look on the right hand side of the page and you can D/L the latest iteration of their C# Coding Standard document.

Hungarian notation was never meant to be used to show what data type the variable was. It was misunderstood to suggest that "str" or "i" be used to implicitly define the type. It was meant to only show the "kind" of variable, not the "type."

So to answer the question, it shouldn't be used now nor should it have ever been used in the past.

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.

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...

Only if you're reading the code outside of the IDE. If it's in the IDE, all the information is available just by hovering the mouse over the variable.
–
Joel CoehoornNov 21 '08 at 16:11

That assumes a lot about the IDE the other reader of the code has available and chooses to use. I do not assume an IDE in my code, and I very much favor the attitude that Frans-WIllem offers here.
–
orcmidNov 21 '08 at 21:27

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.

Is that part of the standard style?
–
James McMahonNov 21 '08 at 16:11

Yes, it is. The MS standard for private member variables (at least in C#, not sure about VB.NET) is to prefix them with underscore. This is useful with the Refactoring tool in Visual Studio. You can right-click on the underscore-prefixed member variable, select Encapsulate, and it will generate the member variable's corresponding property, including getter and setter. Just like this: private int _id; would generate: public int Id { get { return _id; } set { _id = value; } } Sweet!
–
CyberherbalistMay 6 '09 at 20:41

I would say that in most languages these days that have a limited set of types - in particular no concept of unsigned types - then a well-named variable shouldn't need the prefix.

In languages that have signed and unsigned types, or a slew of similar types (e.g. short, int, long or Int8, Int16, In32), then prefixes are useful, despite what anybody else has or will say (and they will, you know it).

The compiler will, at best, give a warning when you try and mix integral types of different signs in expressions, and this could easily be missed if, for example, you configure your IDE to only show errors (not warnings) in a build in the final summary (as you can do with Visual Studio). Mixing signs in arithmetic can seriously ruin your day, so save you or your successor a headache and give them a clue. Remember - you're not the only one who will ever look at the code.

I sometimes use a kind of prefix where pName is a parameter passed into my function (notice I don't prefix the type), oName is local to my current method, mName is a member to the class I'm in and cName is a constant or static readonly member.

I see the point of getting away from Hungarian notation, the standards in our shop forbid it, too, but I still find it useful in my one-off or little utility projects for one reason and one reason only: when I am coding to a large number of controls in a web or win form, using HN makes it easy to use Intellisense make sure I catch every single control while coding.

If I have a five checkboxes and their names all start with chk then typing chk gives me the list of every one of them and I can easily pick which one I'm working on that moment.

Also, sometimes I find myself wondering "what the heck was that checkbox named again?" And I have to break off and look in the .ASPX page again.

One way I have compromised is to begin with HN, and then once I have gotten the main code in a win or web form complete, my last step is to do global renames for the HN-named controls. This has actually worked well for me. YMMV, of course.

I use it all the time but that could because I use VBA with Access and Excel.

For me CountAll is a name intCountAll is a name with this difference that it additionially describes the name (never intended for machines just for humans) like sintCountAll tells me its static pintCountAll private and gintCountAll global so for the purpose I use it; it is very usefull.

control names is a time safer like instead of ControlName I have lblControlName, txtControlName, cboControlName, lstControlName etc so when I use VBA I just type lst and I have all the names I need so I don't have to remember what is the exact name which saves me a lot of time but again this is mainly VBA in Access and Excel.