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

















Pivot Table















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.


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


What I Typically Use

















Pivot Table









Arr (typically an array)






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.



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


  5. Freek van Gilst

    You should really be reading this article: “Making Wrong Code Look Wrong” by Joel Spolski (

    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.

  7. Doug Jenkins

    I’m glad I’m not the only one who doesn’t find Hungarian notation useful. For me it just makes the code hard to read, for no real benefit.

    Charlie Hall makes a good point about using suffix notation with intellisense, which I can see some point in, but that was immediately superseded by the post from Freek van Gilst, with the Ctrl-I tool-tip short cut, which I really should have known about, but didn’t.

  8. John Plant

    Hungarian fits so comfortably with me I use it for my grocery shopping list 🙂 But seriously I’m like you datapig – I use it intermittently because it helps e.g if I’m using a column name and a column number then sCol, iCol helps me a lot more that a less structured pair of names might, I find.

  9. Ron MVP

    I used to work with a (large) company that had a very strict data naming convention that included an element of Hungarian notation. But we used suffixes rather than prefixes.

    Every word used in field names had an approved 3 letter abbreviation. Every date element name was decomposed those TLA’s in a strict syntax. Then the hungarian type notation was used to identify the type of data. In a system consisting of a dozen databases, with hundreds of tables and thousands of unique data element tnames an experienced programmer could translate the names into recognizeable English. Even as a new programmer, we were given the dictionary of elements and abbreviations so we could also translate the names.

    We had a couple of librarians in the DB Admin group who were tasked with generating new field names as required. They would research and confirm that the data was not already named anywhere else in the system, then they generated the approved name.

    When you first look at the programs and tables, yes, they looked like gibberish. And yes, it takes a lot of management, but in the end it resulted in system that was easy to maintain, easy for people to relate data elements between tables and easier to program in, once you were familiar with it.

    Yes, in a situation where only one person is working on a spreadsheet, it may not make sense. Or if it is a “throwaway”. But, I’ve seen too many examples where something called a “throwaway” to justify “fast and dirty, and cheap” solution ended up becoming a long term system that was subsequently enhanced and extended. If this spreadsheet really is useful, at some point someone else is likely to be going to be changing it, maintaining it. So in any situation that is more than a “mom and pop” small business, having a strict system in place can in the long run make data management, and maintenance easier. Like everything else in computing (and life), you can invest in the future by paying a little extra up front, or pay a LOT more in the future to fix past bad decisions.

    So, yes, when I’m working on a speadsheet, I like to take a minute longer and change the default table, and pivot table names to something descriptive, including a hungarian type notation suffix. Granted, in spreadsheets Hungarian notation is not appropriate for column names, but it can be used in VBA and other elements. It makes identifying element types unambiguous.

    But that is just me.

Leave a Reply

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