Why should Hungarian notation NOT be used?

I have been using VB for nearly 10 years (versions 3 thru 6) and have always used a form of "Hungarian" notation. My personal preferences for naming conventions are given below. Now that I have been venturing out into the .NET world, I see that Hungarian is fighting for its life, as the recommendation is NOT to use it. In that I am convinced of the value of using Hungarian to identify the type and scope of a variable, what are some valid arguments AGAINST it (other than the code looks "prettier" without it)?

-------------------------------------------------------------------------
Variable Naming Conventions (for VB6)

Many programmers follow stylistic naming conventions in an effort to improve the readability of their code. The naming conventions involve using a one-to-four character lower-case prefix to start off the name. The purpose of the prefix is to identify the data type of the variable (like "int" for integers and "str" for strings). These naming conventions are sometimes called "Hungarian naming conventions" (after Charles Simonyi, an early Microsoft programmer – and Hungarian native – who proposed the conventions). Two other prominent programmers, Leszynski and Reddick, also have led the charge for naming conventions.

The chart below shows each variable type, a recommended three-character prefix, and a sample variable name:

Code:

---

Variable Type        Recommended Prefix        Sample Variable Name
-------------  ------------------      --------------------
Boolean                bln                        blnDataIsValid
Byte                byt                        bytSmallNum
Currency        cur                        curBigMoney
Date                dtm (for "Date/Time")        dtmEmpBirthDate
Double                dbl                        dblAnnSalary
Integer        int                        intCounter
Long                lng                        lngBigIntValue
Object                obj                        objExcelApp
Single                sng                        sngHrlyRate
String                str                        strMyWord
Variant        vnt  (or "var")        vntWhatever

---

Note the style of using a lower-case, three-character prefix, followed by a descriptive name in mixed case. This is the style of naming variables found in most VB documentation.

It is also recommended that you indicate the scope of the variable with an additional one-character prefix in front of the variable name. My recommendations are:

None for a local variable (i.e., a variable that is declared in a Sub or Function). Thus, variable names like the ones in the sample names above would be used for local variables.

The letter m for module-level variables (variables that are declared with Private scope in the General Declarations section of a code module). Such variables can be "seen" in any Sub or Function of that module. For example, a String variable declared at the module level might be named mstrEmpName.

The letter g for global (project-level) variables (variables that are declared with Public scope in the General Declarations section of a code module). Such variables can be "seen" in any Sub or Function of any module in the project. For example, a Boolean variable declared at the project level might be named gblnFirstTime.

The letter p for a variable that is passed as an argument to a Sub or Function procedure. Such a variable would have local scope within that procedure, but it is defined within the procedure's header. For example, an Integer variable passed to a Sub might be named pintCurrCode when defined in the Sub's header.

In addition, it is recommended that the letter a be used to indicate an array name. In an array name, the letter "a" would appear before the variable type indicator, but after the scope indicator. For example, an array of Boolean switches might be named as follows, depending on where it is declared:

Code:

---


            ablnSwitches    local level
            mablnSwitches    module level
            gablnSwitches    global (project) level
            pablnSwitches    passed parameter

---

Naming Conventions for Constants

Similar to naming variables, use the lowercase three-character datatype prefix ("int", "str", etc.), prefixed by an "m" if a module-level constant or "g" if a global (project-level) constant. However, for the main part of the name, use all capital letters (with underscores to break up individual words within the name).

Sample Constant Declarations:

Public Const gsngTAX_RATE As Single = 0.06
Private Const mdtmCUT_OFF_DATE As Date = #1/1/1980#
Const strERROR_MESSAGE = "Invalid Data" 'String data type assumed

well I use it still for some things but have been moving away from it as well... The reason (opinion alert) that it is dying as you say, is because it was pretty much brought around in the time of short variable names and such, before intellisense or smart IDEs...

Pretty much the only thing I still use it for is form controls/components.. but not for variables...

The IDE is so powerful now, that mousing over will give you the information about the variable you are working with (so will intellisense) so the hungarian notation all of a sudden becomes 3+ unneeded letters in the variable name.

That and I feel like there are just SOOOO many objects and types now that you simply can't get good hungarian notation for a lot of objects.. the abbreviations that would be the logical choice either are already taken or you can't get right in 3 or so letters.

I use My a lot when creating variable, especially in a local scope

Dim MyDataReader as DataReader, etc...

makes it easy to know its YOUR variable, and what data type it is.. If I need more than 1 object of the same type in the same scope, I will make them slightly more descript.

Dim MyDataReaderFeed1
Dim MyDataReaderFeed2

or something like that

I used to hate long variable names until I found the power of ctrl + spacebar intellisense.

While we're at it, is using underscore for module level variable OK?

e.g

VB Code:

Class Demo01
   Private _Surname as string
   Private _FirstName as String
   Public Property Surname() as string
       Get
           Return _Surname
       End Get
       Set (byval Value as string)
           _Surname = value
       End Set
   End Property
End Class

On another node I've noticed that in some samples while referencing class level variables in methods within a class they still use Me.Surname instead of directly using _Surname. I thought there would be a overhead in accessing the Surname through through the property. Could someoen shed some lights.

Thanks

I'm with Kleinma on this one. Hungarian notation actually hinders the IDE, it forces you to prefix with loads of needless characters before intellisense gets anywhere near the variable you want.

I tend to use my own style, a variant of CamelNotation.

underscoring is fine. it saves you having to resort to changing case of the leading character and confusing yourself, I normally use underscores but lately i've been getting slack on this issue :D

Good point.

Everything that Kleinma said plus in an Object word hungarian (my opinion) makes it less readable and less focused on the objects themselves. It drags the type into the name instead of focusing on the concept. It also messes up any sort of sorted list you may have of you objects. They would be grouped by type instead of by concept.

Primarily it is just personal preference though.

Quote:

---

Originally Posted by Mr.No

While we're at it, is using underscore for module level variable OK?

On another node I've noticed that in some samples while referencing class level variables in methods within a class they still use Me.Surname instead of directly using _Surname. I thought there would be a overhead in accessing the Surname through through the property. Could someoen shed some lights.

Thanks

---

yes I use _ when dealing with private module level variable

as far as your second comment, it really depends..

if you just want the RAW value of _Surname, then that is the variable I would use.. and if my class was set up as yours then that would be fine.. sometimes though you may want to use the public property, depending on what it does.. not all public properties return just the private version of them, sometimes they will have additional coding in them as well, for example

VB Code:

Class Demo01
   Private _Surname as string
   Private _FirstName as String
   Public Property Surname() as string
       Get
           if _Surname = string.empty then
               return "No Surname"
           else
               Return _Surname 
           End If
       End Get
       Set (byval Value as string)
           _Surname = value
       End Set
   End Property
End Class

so if you want the raw value, use _Surname, but if you want the public property, which will give you "No Surname" when the private variable is empty, then you would use me.surname (the property)

because technically, if your property didn't do any other function except for assigning or getting a value from the private variable.. then your private variable might as well be public, and ditch the public property..

oh yeah BTW, I usually make each seperate word in a variable capital.. I think most people do that though.. I know in languages like C they often use the same, but lowecase the first word...

I think that is ProperCase, but I may have it wrong.

I use that style for functions and classes, but leave the first word lower case for variables. There is no really good reason to do this, since I generally know that the item is a variable. Habit by now, I guess.

I hate underscores because they are awkward to type. Breaks up the flow of the typing. The only other thing I started doing was using m for member on variables in class definitions. There is little advantage to doing this, but it can prevent some name collisions, such as where a variable has such an obvious name that it ought to be used, but it ought to also be used as a property name.

I noticed MS programmers often times use _ in their examples.. that is where I picked it up from... it is a little annoying to type at first, but I got very used to it very fast.. the best part is, when using the variable autocomplete in intellisense, or just intellisense in general, it groups all your variables by the _

if you use m, any object alphabetically (not just including your own variables, but any that are visible in the current scope) in between your module level variables will be all mixed in..

Thanks for your input, gentlemen, I will be taking your comments under advisement. I would like to have this issue (as trivial as it may be to some) "settled" in my mind as I get deeper into .NET. It's just something I'll have to think about until I decide on the conventions that make sense to me.

Quote:

---

Originally Posted by kleinma

the best part is, when using the variable autocomplete in intellisense, or just intellisense in general, it groups all your variables by the _

if you use m, any object alphabetically (not just including your own variables, but any that are visible in the current scope) in between your module level variables will be all mixed in..

---

That's a good point. I started using _ years ago, but then found it too annoying, and moved away from it. I like the idea of all of the items clustering together, but I find that just a bit of warting does that for me. I add b for buttons, l for labels, etc. Though this does not lump them perfectly, it gets them fairly close, and I only need the next letter to get to most anything.


It all comes down to style. You have one, and it slowly changes over time (unless you have an institutionalized style). Go with what feels good to you.

I think you're talking about Pascal Notation, perhaps?

My personal preference is the good old Hungarian Notation. My reason is, as I type and code, I don't want to use the mouse much. I like to keep my hands on the keyboard, and I don't want to have to rely on a mouse to give me a tooltip to tell me what a variable is. I code faster this way.

Also, take a look at some code snippets posted on the forums. If someone just shows us a function they wrote using a class-level variable, I can't tell what it is just by looking at it, unless there's a clue in there. Know what I mean?

But in the end, the real answer to your question is, whatever you personally prefer.

And remember, I'm always right.

i still use the hungarian notation despite that MS says it's bad lol
i dont like MS's replacement for hungarian either MS wants you to:
firstnameTextbox
calculateButton
firstnameString

i dont like that