Hungarian notation in C?

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.

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.

We've had this discussion before, and I can totally see the point of "Apps Hungarian" but I would like to point out that in C++ this also wasn't necessary, if you use the technique described in Scott Meyers' book "Effective C++", Item 18, page 78. – Dave Van den Eynde Apr 20 '09 at 14:05 2 I've got the 2nd Edition and Item 18 is "Strive for class interfaces that are complete and minimal" which isn't related to this. – 17 of 26 Apr 20 '09 at 14:11 2 I don't see the point in Apps Hungarian when the IDE can tell you if something is a member variable.

– Camilo Martin Nov 2 '10 at 6:44.

You're not the only person, but I'd say it's relatively uncommon. Personally I'm not a fan of Hungarian notation, at least not in the simple sense that just restates the type information which is already present in the declaration. (Fans of "true" Hungarian notation will explain the difference - it's never bothered me that much, but I can see their point.

If you use a common prefix for, say, units of length vs units of weight, you won't accidentally assign a length variable with a weight value, even though both may be integers. ) However, for private members you can pretty much do what you want - agree with your team what the naming convention should be. The important point is that if you want your API to fit in with the rest of .

NET, don't use Hungarian notation in your public members (including parameters).

3 Dang, I said the exact same thing, just slower. I'll delete my post. – Jacob Adams Apr 20 '09 at 13:37 @Jon : they say using hugarian is not a good practise but any real issue?

Does it cause any harm specifically (effeciency/compiler issue anything )? Persoanlly I don't use it in my class but for the visual items like textBox,labels etc I use txt and lbl 's respectively. Please comment.

– SilverHorse Apr 20 '09 at 14:14 1 No, variable names don't change efficiency or compile-times etc. They affect readability more than anything else. (Oh, and varying public members just by case will limit the ability to use the type from case-insensitive languages such as VB.) – Jon Skeet Apr 20 '09 at 14:28.

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

When doing user interface design, I have found it very useful to maintain Hungarian notation. Items like text boxes, labels and drop down lists are much easier to quickly understand and often you get repeating control names: lblTitle = Label txtTitle = TextBox ddlTitle = DropDownList To me that's easier to read and parse. Otherwise, Hungarian notation doesn't fit in because of the advances in IDE's, specifically Visual Studio.

Also, Joel on Software has an excellent article related to Hungarian notation titled: Making Wrong Code Look Wrong which makes some good arguments for Hungarian notation.

7 I disagree. I think it is even worse in this case, especially when you get into controls with longer names or the 3 letter abbreviation clashes with the 3 letter abbreviation of another control. We instead use TitleLabel or TitleTextBox or TitleDropDown etc.– John Apr 20 '09 at 13:46 1 @John: I totally agree.

There's no character limit for us and we should make the variables nice and readable. – Jeff Yates Apr 20 '09 at 13:56 1 @Jeff & John - Just because we have no character limit doesn't mean it should be used. Smaller succinct variables > Longer expressive variables – Gavin Miller Apr 20 '09 at 14:07 1 I still disagree.

There is little justifiable reason for terseness over descriptiveness. A variable name should be as long as it needs to be. There is a happy middle ground between m_lblName and theLabelThatHoldsSomeonesName.

– Jeff Yates Apr 20 '09 at 14:12 1 I do this too, and I think it makes perfect sense. More often than not you'll be working on your controls from the code-behind, and the objects aren't declared there, but rather in some mark-up. I like to know the type of the stuff I'm working with from codebehind, without having to look in the markup :) – cwap Apr 20 '09 at 14:59.

You're certainly not the only person, but I do hope you're part of a declining trend :) The problem with Hungarian notation is that it's trying to implement a type system via naming conventions. This is extremely problematic because it's a type system with only human verification. Every human on the project has to agree to the same set of standards, do rigorous code reviews and ensure that all new types are assigned the appropriate and correct prefix.In short, it's impossible to guarantee consistency with a large enough code base.

At the point there is no consistency why are you doing it? Furthermore tools don't support Hungarian notation. That might seem like a stupid comment on the surface but consider refactoring for instance.

Each refactoring in a Hungarian naming convention system must be accompanied with a mass rename to ensure that prefixes are maintained. Mass renames are susceptible to all sorts of subtle bugs. Instead of using names to implement a type system, just rely on the type system.

It has automatic verification and tool support. Newer IDE's make it much easier to discover a variable's type (intellisense, hover tips, etc ...) and really remove the original desire for Hungarian Notation.

Very well said, +1 – John Apr 21 '09 at 0:31.

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

The IDE can provide the type, but only if I waste a second of my time hovering over the variable name :-) I'd rather be able to see it at a glance... And to provide a counterpoint to your example: exePath might well be a System.IO. FileInfo object, a wrapper for a file path that provides easy access to common file system operations. I honestly don't see the harm in prefixing variable names.

I find that it makes code inspection and debugging easier. – Jordan Rieger Nov 11 '11 at 22:21 What do you need the type for though? When I program, I want to know what a variable represents, not which type it is.

If your exePath is of type FileInfo, it's badly named, and then that is your problem. The variable's name says that it is a path, not an actual file. So when I use it, I expect it to behave like a path name, and not like a file.

– jalf Nov 12 '11 at 11:18.

Unless you are using a text editor rather than the VS IDE there is little value to hungarian notation and it impeeds rather than improves readability.

One downside of Hungarian notation is that developers frequently change the type of variables during early coding, which requires the name of the variable to also change.

2 Agreed, it does add a maintainance burden to a codebase. – Richard Ev Apr 20 '09 at 13:42.

The only two areas where I currently see any form of Hungarian notation are: Class member variables, with a leading underscore (e.g. _someVar) WinForms and WebForms control names (btn for Button, lbl for Label etc) The leading underscore on member variables seems like it is here to stay with us for a while longer, but I expect to see the popularity of Hungarian on control names to wane.

I avoid any leading underscores to avoid running afoul of C++'s naming requirements. Yes, I know this is C#... – Dan Apr 20 '09 at 16:38.

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.

If you hold the pointer over the variable in VS it will tell you what type of variable it is, so there is no reason to go with these cryptic variable names, esp as people that are coming from other languages may need to maintain the code and it will be an obstacle to easy reading.

The real value in Hungarian notation dates back to C programming and the weakly typed nature of pointers. Basically, back in the day the easiest way to keep track of the type was to use Hungarian. In languages like C# the type system tells you all you need to know, and the IDE presents this to you in a very user friendly way so there is simply no need to use Hungarian.As for good reason to not use it, well there are quite a few.

FIrstly, in C# and for that matter C++ and many other langause you often create your own types, so what would be the Hungarian for a "MyAccountObject" type? Even if you can decide on sensible Hungarian notations it still makes the actual variable name slightly harder to read because you have to skip past the "LPZCSTR" (or whatever) at the start. More important is the maintainance cost though, what if you start of with a List and change to another type of collection (something I seem to do a lot at the moment)?

You then need to rename all your variables that use that type, all for no real benefit. If you had just used a decent name to begin with you wouldn't have to worry about this.In your example, what if you created or used some more meaningful type for holding a path (e.g. Path), you then need to change your m_strExePath to m_pathExePath, which is a pain and in this case not actually very helpful.

Most C++ programming standards say exactly the same thing.

In a language like C# where many of the limitations on variable name length do not exist that were once in languages like C and C++, and where the IDE provides excellent support for determining the type of a variable, Hungarian notation is redundant. Code should be self-explanatory so names like m_szName can be replaced by this.name. And m_lblName can be nameLabel, etc.The important thing is to be consistent and to create code that is easy to read and maintain - this is the goal of any naming convention so you should always decide what convention you use based on this.

I feel that Hungarian notation is not the most readable or the most maintainable because it can be too terse, requires a certain amount of knowledge on what the prefixes mean, and is not part of the language and therefore, hard to enforce and hard to detect when the name no longer matches the underlying type. Instead, I like to replace Apps Hungarian (prefixes like m_) by referencing this for members, referencing the class name for static variables, and no prefix for local variables. And instead of System Hungarian (including the type of a variable in the variable name), I prefer to describe what the variable is for such as nameLabel, nameTextBox, count, and databaseReference.

Most hungarian notation describes what the variable is (a pointer, or a pointer to a pointer, or the contents of a pointer etc. Etc. ), and what the thing that it points to is (string etc). I've found very little use for pointers in C#, especially when there's no unmanaged/pinvoke calls.

Also, there's no option to use void* so there's no need for hungariant to describe it. The only left-over from Hungarian that I (and most others in C# land) use, is to preceed private fields with _, as in _customers.

At some point, you're likely to have a property public string ExecutablePath { ... } (not that you should try to avoid abbreviations like "Exe" too). That being the case, your question might then be moot much of the time as you can use C# 3.0's auto-properties public string ExecutablePath { get; set; } you now no longer have to come up with a name for the backing store variable. No name, no question/debate about naming conventions.

Obviously, auto-implemented properties aren't always appropriate.

This answer has no relation to Hungarian notation. It belongs to a question that asks "should I name my private member _executablePath or m_executablePath or executablePath? ", not this one.

– Lucas Apr 20 '09 at 18:23 typo-means-the-opposite alert: "NOTE that you should try...", – Lucas Apr 20 '09 at 18:24 Use automatic properties -> no (or at least less) need to even think about such naming conventions. – Dan Apr 20 '09 at 19:36 Yes, but public properties' private backing fields is a small fraction of all variable names. There are also public property names or local variable names.

What you're saying is right, it just hardly answers the question :) – Lucas Apr 22 '09 at 19:33 1 I think that a large enough percentage of member variables are exposed as simple properties to make this observation worthwhile (certainly undeserving of the downvote :-) ). – Dan Apr 22 '09 at 19:45.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.