Why the world hates Hungarian notation?

[The Nightcoder]

Exactly what does m mean? I've seen it for years and never understood the point - I thought it was just some kind of typing mistake that spread? For private members (oh - maybe it means member - but no, people never use it on public members, so it can't be that) I used to use the "p" prefix... but ended up with "_" instead (after a short period of camel casing - but it ended up being too hard to spot unintentional recursions then - and also, camel casing is reserved for parameters). But... back to the original question. What does the "m" or "m_" prefix on private fields in a class really mean? Ten years since I first saw it (and barfed on it), still no clue... :)

Peter the small turnip (1) It Has To Work. --RFC 1925[^]

[The Nightcoder]

Just a thought: Maybe the project is too big then? And by project I mean (in the VS sense) project, not solution. Even if you have a huge solution, it's usually sufficient to check out a project - since it will include the output (DLL:s, for example) from the other projects it needs. That way, you get full intellisense, mouseover type information and so on (for instance, you can view metadata and declarations of classes from the other projects) even without checking out the entire solution. Viable?

Peter the small turnip (1) It Has To Work. --RFC 1925[^]

[jsc42]

I work for a company (which shall remain nameless) which has locked down PCs where downloading software is a disciplinary offence (even if you could break the security model to do it). Therefore, I do not have Visual Studio and Notepad (on Windows) and vi (on Unix) are my daily tools. And as for using a Terminal Server from home to access a work's machine; that would break national security rules. So, enjoy your insecure environment - you are one of the lucky ones; at least until you accidentally download a product that bypasses your malware alerts.

[The Nightcoder]

Haha, That's why I like working for a small company... :) But seriously, our environment isn't really that insecure. I don't download any software (can't even see that I mentioned downloading software) that isn't licensed or free and approved (although I do the approving here), and I don't run any of the tools on any computer that isn't owned by the company (usually, my work laptop). Termial services access is over SSL and we have a reasonably secure password policy. It doesn't violate any security policy at all (since I write the security policies, I know). But... I mostly write customer specific back-end software for web sites - code that is useful in one and exactly one place... so if someone WOULD get at it, it wouldn't be much of a problem anyway. But I can understand your situation. Was a while ago since I used "vi"... almost 30 years now... some things never die... :)

Peter the small turnip (1) It Has To Work. --RFC 1925[^]

[ThatThatGuy]

Agreed to the fact that, Hungarian notation helps us to identify the variable type.. But in the modern world of OO programming where we mostly now-a-days with custom classes and entities. You will mostly be using Custom types for your variable. In that case its seen people will use objFirstCustomer where obj will stand common for all of the custom types... which doesn't show what data type it is. Or you'd better name its as curManFirstCustomer where the same curMan doesn't even will denote what type of object is it. So thus its completely meaningless to use hungrily notation... where its doesn't serve the purpose fully... Also normal .Net notation keep your code neat, presentable and shows more uniformity...

[Thomas Eyde]

A more interesting question is, why do you need to know the type in the first place? My take against it is code without prefixes are more readable. If the variable name tells me nothing, then the name is the problem, not the type or lack of prefix. Another thing is I find it impractical. It's easy to find prefixes for primitive types, but what about custom types? Should we invent prefixes for all of them? What if we do, doesn't accAccount look pretty stupid?

[David Roh]

Well, I am a firm believer in Hungarian and here is why - I believe that the name of a variable should instantly convey three vital pieces of information to the dev: - it's type and I do mean type as in compiler typeof not semantics (regardless of what Charles did or did not intend) - it's scope - is it local, a parameter, is it a passed in reference, a class level variable - a clear indication of it's function or purpose Different devs have their own view on how to write code; however, I believe that it's better to have a good logical reason for a belief rather than just a prejudice. I believe that one of the reasons that Hungarian is considered bad is due to the way that many devs implement it - that is, each group uses very short abbreviations that are not clear to someone who is not part of the team so when you look at another teams code, you have to learn their abbreviations. Different teams have different rules and different ways of implementing Hungarian which make it a hassle to read another teams code. I believe that it is not Hungarian that is the problem but rather the way that it is implemented that is the problem. First we do very little abbreviation and only if it is an abbreviation that is so common that a noob would clearly understand it. We use longer names - yes we believe in self documenting code which means my manager should be able to read my code and understand what is being implemented in general terms (we don't however go to extremes). If a passed in parameter is a reference that will live after a function is finished, then it is important to know that altering it can have long term consequences. If a variable is a class level variable, it is extremely important to know. It should also be obvious that the more accurate the variable name clearly indicates it's purpose and function, the less potential there is for another dev to misunderstand or the original dev when returning to old code. Saying that Intellisense will solve the problem or that we can mouse over a variable is not a solution because when we read code and think we understand, we rarely mouse over or use Intellisense on what we think we already understand. Saying that Hungarian is bad because the type might change is a really weak argument - in the first place, types don't usually change that much; second, if a type does change, I certainly want to know; and lastly, with today's IDE refactoring capability, is really that hard to change a variable name (it's certainly easy for me). We c

[David Roh]

Custom types are easy - I just use the class name only starting with a lower case letter

[Lost User]

I don't care for Hungarian notation because it doesn't add any useful information. Consider the following two variable names: CustomerName strCustomerName There is no added value to the 'str' prefix in that example because both variables are obviously string variables. All my variable names have a tendency to make their type obvious - there is no reason to use short, confusing names where a particular notation is required. The tool tip will tell one the type anyways.

[David Roh]

I use the class name only with a leading lower case letter for local and add m_ for class level s_ for static and p_ for parameter - it's easy. It may look ugly but it's clear.

[Lost User]

I understand #2 but it's a wee bit silly. How often do you change a variable type - and even if you did the IDE asks to change all of 'em for you. It takes 3 seconds.

[gritter55]

Are you going to add accountNumber's together? Are you going to divide on accountNumber by another one? An ex-coworker of mine use to make anything called a number (SSN, phone, account) a numeric type and it would drive me crazy.

[Fran Porretto]

Hungarian Notation expresses data type, but it does nothing for, and can even obscure, data semantics. I'm sure that was no part of Charles Simonyi's intent, but it does seem to work out that way quite often.

The old guideline that one should keep one's procedures / functions / methods short enough to be completely viewed on the monitor screen tends to produce the best legibility. If you can see everything at once, it's more difficult to go astray about either type or semantics.

My personal practice is to keep procedures as short as possible -- it's been a long time since I last wrote a procedure that can't be displayed in its entirety on the screen -- and to adhere to an inside / outside convention regarding variable names:

• Variables declared inside the procedure will have short names, with the exception of static variables whose significance extends beyond individual invocations of the procedure.
• Variables declared outside all procedures will have long, maximally descriptive names, since this is the space in which most problems of coupling and timing arise.
• Of course, those "outside-all-procedures" variables will be minimized in number, and protected from thread collisions with mutexes as appropriate.

Now, I'm a real-timer; my applications are always heavily multi-threaded, and I'm always intensely concerned with attaining a reliably predictable response time to any imaginable event. If you do other sorts of programs, you're likely to have different desiderata...but I can't imagine that the conventions described above would harm you, even so.

(This message is programming you in ways you cannot detect. Be afraid.)

[Ennis Ray Lynch Jr]

You are not supposed to have "public" members. You are supposed to have non-public members with exposed setters and accesors. It is actually possible to program without exposing any data, although it is tedious. Properties confuse the fact in .NET. When I did java, I could have a member customerId, and a setCustomerId, and a getCustomerId and the world was perfect. In .NET if I don't do automatic properties, I really need someway to differentiate between customerId and CustomerId for the VB crowd; so I use m as member: mCustomerId.

Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. I also do Android Programming as I find it a refreshing break from the MS. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost

[zighouse]

So, you may like

m_spszAccNumber

better? Without understanding the definite meaning of a variable, how can you dare to apply any operation on it?

[ferahl]

I used Hungarian notation in C++ all the time as it is close to the machine and so things like pAddress and ppAddress and dwAddress and lpdwAddress and wAddress, or sStructure and tTypedef etc are very useful distinctions. With higher level languages I tend not to annotate strings, and booleans are usually posed as a question like hasLoaded, isUserFemale. Though annotations to suggest private / protected variables like the underscore (_) I still find useful. We don't often have to consider whether something is 16, 32, or 64bits long though, and we rarely access raw pointers so pAddress and ppAddress have less use, and sStructure and tTypedef are generally just full classes at the detriment to performance. Also we use var a lot and let the compiler define the type so this is another factor. The next factor is the IDE, if the solution is fully integrated like in MS Visual Studio then you can easily go to the definition or hover over the variable so it is less necessary. Though as you say C&P'ing snippets elsewhere and you won't always know what they are though you can usually guess primitives and anything complex you will need the class/structure/typedef anyway. So I would say - carry on for C/C++, ASM etc but for higher level language where vars are often chosen at compile or even runtime then sometimes it is ok to leave it out.

[The Nightcoder]

Hi, Thanks for the enlightenment! I was almost sure that this was the case, although most of the examples I've seen say "m_CustomerId" instead of "mCustomerId". My confusion on this probably comes from interpreting the word "member" as meaning "property, method or field", which is probably incorrect. I write _customerId myself when I need a shadow field for a property called CustomerId. That also works well. Incidentally, that's how I wrote struct field names meant to be private - which wasn't possible to enforce back then - in C back in the early 80's. I think most people did - it became a habit to see it as a bug to touch something starting with _ unless you owned (had defined) it. So using that convention now feels quite familiar and natural. When I work with other people's code I generally don't have any problem with different styles, as long as ALL public identifiers (including parameters - camelCased) strictly follow the .NET guidelines. When you've chosen your environment, stick to its conventions - otherwise you're just confusing the people who use your stuff. Most people seem to follow them, though. I occassionally see camelCasing of classes, methods and properties, but that usually only happens when a web designer/javascript coder makes an occassional visit to .NET (and that code comes to me for refactoring anyway, as a matter of procedure)... Later,

Peter the small turnip (1) It Has To Work. --RFC 1925[^]

[wrocca]

Then you would be wrong if you were using data from my Database. I only use numeric data types for data on which you can do math. You would never want to "add" two account numbers - maybe some sort of concatenation, but never add. "You can't do today's job with yesterday's methods and be in business tomorrow." -- Anonymous So, "Never interrupt someone doing what you said couldn't be done." -- Amelia Earhart

[Fabio Franco]

So far, no matter what, a great potential for confusion arose between CP members, imagine in between non-hamsters.

"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson "Our heads are round so our thoughts can change direction." ― Francis Picabia

[Gary Huck]

Duh.