Why the world hates Hungarian notation?

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

[Gary Huck]

Right vs. Wrong: it's just not that simple. A lot of the things in the world of development are personal preferences. The starter of this thread likes Hungarian; you guys don't. No big deal. Personally, I find Hungarian to be very handy *a lot of the time*. Not always. I maintain that it's a bad idea to be hard and fast on topics that are really just "programmer prerogative". (I don't use notepad to read code any more but, jeez, if you're stuck with that ... Hungarian would be great! :)

[Fabio Franco]

VuNic wrote:

I just open it in notepad and try to figure out what datatypes all these variables are.

Well, I might not know why you're using notepad instead of VS. But couldn't you at least use Notepad++? I mean, you can't be doing this for nostalgia purposes only. Or could you?

"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

[Stuart Rubin]

Before writing the coding standard, I would recommend reading "Code Complete" which gives some very specific arguments about naming conventions and other things that would be in the standard. The good news is that no matter what, just HAVING the standard, even if it's not perfect, will go a long way. For our company which is largely focused on embedded projects using C, we adopted one that was already well developed (Michael Barr's Netrino embedded standard), bought a few hard copies for our reference, and made a one or two page document that says that's what we're using and what changes to it we're implementing (very few tweaks). Taking this route (adopting an already written standard) saved us a TON of time (read money) and took out some of the "persona preference" discussions. If you're using C#, why not adopt Microsoft's standard and call it a day? (I realize this isn't exactly what you were asking about.)

[BinaryReason]

Back in my embedded C and MFC days I used to be big on hungarian notation. No more. These days I am working mostly with C# and stay away from prefixes as much as possible for a few reasons. 1. Readability As programmers we spend most of our time reading code not writing it. What's easier to read: sAccountNumber = CreateAccountNumber(nId, sLastName, wUniqueId); or accountNumber = CreateAccountNumber(id, lastName, uniqueId); 2. Maintenance Let's say I no longer want to use a string to store my account number. I want to encapsulate it inside a class. If you used accountNumber variable to begin with, you don't need to worry about renaming it. It's still just an accountNumber With modern compiler GUIs you really don't need to encode the variable type in it's name. You can hover with your mouse over it, and find out immediately whether it's an int or a string, or some other user defined type. In fact, you should try to avoid thinking about storage types as much as possible, and program at a higher level of abstraction. Only when you get to the low level code, take care of the types. I highly recommend Robert C. Martin's "Clean Code"[^], particularly Chapter 2: Meaningful Names apply to this discussion.

"There are only 10 types of people in the world - those who know binary and those who don't."

[TheGreatAndPowerfulOz]

It occurs more often than you might be aware.

If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun

[MacSpudster]

Ah, yes, the assumption factor. When often engaged upon, oft required is the element of REfactoring! These might be more specific: thisVarIsASignedIntegerBuddyBoy dontUseThisVarToStoreNumbersBuddyBoy noSpacesOrUnderlinesAllowedBuddyBoy :wtf:oh_AndHereIsAnExceptionColumnForYouBuddetteGals_JustInCase :wtf: ;P

The best way to improve Windows is run it on a Mac. The best way to bring a Mac to its knees is to run Windows on it. ~ my brother Jeff

[MSBassSinger]

I prefere Hunarian notation for the same reasons. We don't always have an IDE handy when reviewing code. I use "m_" for module-level scoped variables, and no prefix for variables local to a given method or property. So, what prefixes would you use for the following (and their array counterparts where arrays make sense): Int16 Int32 Int64 UInt16 UInt32 UInt64 String DateTime Single Double Boolean Dictionary/Dictionary<> List/List<> or a variety of other objects? Your choices could be helpful to us Neanderthals still using Hungarian notation?