Why the world hates Hungarian notation?

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

[TheGreatAndPowerfulOz]

Well argued. I simply disagree. Variable types change a lot more than you seem to be aware. Especially in an agile environment. If a variable is given a descriptive enough name, then it's underlying type is already apparent in the name. Hey, but if it works for you go for it. I'll never read your code and won't work somewhere where it's required.

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

[MSBassSinger]

"m" most often means "module" for variables scoped to class. For example, if you have a CustomerID property, then having a m_CustomerID variable declared at the class level is the anchor for the value that the property (and other code in the class) can access. Fields are rarely ever appropriate in professional code.

[The Nightcoder]

MSBassSinger wrote:

Fields are rarely ever appropriate in professional code.

You meant "public fields", right? :) By the way, that is stressed in the .NET FrameWork class design guidelines as well, and the reasons are good and many.

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

[MSBassSinger]

CustomerName could also be a class. such as (in shorthand): class CustomerName String FirstName String MiddleName String LastName Int32 SalutationID Int32 TitleID

[MSBassSinger]

Yes, public fields. Good catch.

[Lost User]

While I doubt anyone would create a CustomerName class, I think your point still stands. Regardless, I've never found Hungarian Notation to have enough benefit to stick with it - and that is after having used it for years. If someone else wants to use it that's fine with me.