Me vs Hungarian Notation

Hungarian Notation is a coding convention that many programmers use to (presumably) make their code more understandable.

It involves prefixing variable names with a kind of code that describes the “type” of variable you’re seeing in the code.

For example, if a variable is a Range object, you would name that variable rngSomeName.

Prefixing the variable name with rng allows the reader of the code to immediately know the variable is a range.

Here is a table of a few commonly used Excel objects and the universally agreed upon Hungarian Notation for each.

Variable Type

Hungarian Notation

Boolean

bln

ChartObject

cho

Collection

col

Comment

cmt

Date

dat

Double

dbl

Long

lng

Object

obj

Pivot Table

pvt

Range

rng

Shape

shp

String

str

Variant

var

Workbook

wbk

Worksheet

wks

 

I personally go through periods of really trying to use Hungarian Notation (mainly out of the fear that I’m a hack).

But I inevitably abandon the effort.

Mostly because I just can’t be bothered. I mean let’s face it. I’m not building the next PayPal here. Most of my code is for me to figure out.

Also, I feel as long as my variable declarations are reasonably close to the point where I use them, I can quickly look at the declaration if I have to.

AND

To some extent (like one commenter wrote on Stack Overflow):

“vUsing adjHungarian nNotation vMakes nReading nCode adjDifficult”

 

My Fool-Proof System

I thought it would be fun to list my amazing system of naming variables.

Try not to faint from the brilliance.

I’m a tired 45 years of age (and this table really shows it).

Variable
Type

What I Typically Use

Boolean

blnSomeName

ChartObject

MyChart

Collection

MyCollection

Comment

MyComment

Date

MyDate

Double

x

Long

x

Object

MyObject

Pivot Table

MyPivot

Range

MyRange

Shape

MyShape

String

MyString

Variant

Arr (typically an array)

Workbook

wb

Worksheet

ws

 

Maybe, one day, I’ll come up with a serious naming convention that will change the face of programming. Although, that’s not likely.

Feel free to share any thoughts on the naming conventions you use.

 

 

7 thoughts on “Me vs Hungarian Notation

  1. Jan Karel Pieterse

    I like to be brief…-ish.
    That is, when it comes to the prefixes.
    My Table:

    Type | Example
    Boolean | bOK
    ChartObject | oCht
    Collection | colCollection
    Comment | Never used the comment object before, probably oComment
    Date | datDate
    Double | dSomeVariable
    Long | lCt
    Object | oSomeObject
    PivotTable | oPt
    Range | oSourceRng
    Shape | oShp
    String | sAnswer
    Variant | vData
    Workbook | oWb
    Worksheet | oSh

  2. Jan Karel Pieterse

    O, By the way: I find the more important prefix is for variable scope:

    Local to routine | no prefix
    Module-level | m
    Public (Global) to project | g
    Public in Class | No prefixes
    Constants (anywhere): | All CAPS

  3. Patrick Matthews

    Generally speaking, I can’t be bothered to go Hungarian. In my opinion, if I make my variable names descriptive enough, it should be easy to figure out what the type is. For example, would “CompanyName” ever be anything but a String? As to Boolean variables, I usually make the verb to be part of the name. For example, I would name a variable which tracks whether or not a workbook was already open at runtime something like “WbWasOpen” or “WbIsOpen”. The is/was signifies to me immediately that I looking at a true/false value.

  4. Charlie Hall

    I find Hungarian very useful but only when it is added as a suffix (row_count_l, RowCount_ml, is_found_b, _rng) – Intellisense is so powerful and efficient, but I rarely remember the exact type of my variables – whereas I can guess the starting few letters of my variable names and intellisense provides the filtered list. Then when the variable name is inserted into the code, I can see the type which reminds me to think of how the type may affect the line of code.

    I do find that standard variable names such as name (string), count (long), index (long) I don’t bother with the suffix either. But most non-standard names I still do and find it useful.

    Charlie

  5. Freek van Gilst

    You should really be reading this article: “Making Wrong Code Look Wrong” by Joel Spolski (http://www.joelonsoftware.com/articles/Wrong.html)

    In short: it will help you more to use a kind of Hungarian notation with technical or business information instead of with a data type like Jan Karel Pieterse proposes.
    In the VB editor you don’t really need to have the data type in the name of a variable. When you have the cursor on a variable you can press Ctrl-i to get a tooltip with the type. Or press Shift-F2 to jump to the declaration (and Ctrl-Shift-F2 to return to your original position).
    For example, it will give you much more useful information when you call a variable FullTimeWagePerYear (or better, shorten it to ftYrWage and make a list of similar standard shortcuts you use) than dWage. Because then you immediately see that your code is wrong when you write a formula like (12 * ftYrWage).

    Also for me, adding an abbreviation of the scope to a variable name gets in the way of refactoring code. Because then you’d have to rename variables when you change their scope. This info you can also quickly find in the VB editor with the Shift-F2 trick. (but then again, my programming style hardly ever uses global or module level variables so your experience may be different)

  6. GMF

    I use both the Hungarian prefix and the suffix. Probably too much belt-and-suspenders but when I’m passing parameters to subroutines and functions it helps make sure I’m passing the right type. For basic looping variables I’ll just use the suffix (e.g. I%, j%)

    I generally don’t have unambiguous variables so I can’t have unambiguous variable names. Our purchase orders start with two zeros so the variable PurchaseOrderNumber has to be a string. Ditto for a Global Location Number since we have to treat that as a string.

    If I just need one variable of a certain type (e.g. chart) then I stick with MyChart, but if I need two or more in the same routine (e.g. copying a chart’s line colors to another chart – no it’s not a template) then I want something more descriptive than Chart1 and Chart2. chtSource and chtTarget for example.

    The notation also helps me keep my variable names short(er) than they would otherwise have to be. The longer the variable name, the more chance I have to fat-finger the typing.

    Ultimately I think it’s what you can keep in your head. If you’re writing code all day and you use every function and subroutine in your arsenal at least once a month then I think you can do what you like. If you only code when you need something new and rely on routines you wrote 6 years ago and touch once a quarter then the notation absolutely helps.

Leave a Reply

Your email address will not be published. Required fields are marked *