My case for Hungarian Notation

There are many haters of Hungarian Notation. Prepare to pile on.

I’ve had this post in my drafts queue for a long time but this thread about escaping SQL reserved keywords on the Transfer group prompted me to finish my thoughts:

Most applications have a User table, if those users are organized then there may be a Group table, and if there’s any kind of e-commerce going on then it might have an Order table. How would you name these so as not to use reserved words?

I learned Hungarian Notation from a Sybase database admin named Rick when I first started webdeving back in 1994. He worked at Prudential and I had never touched a database so when we started doing some more serious work, he told me about the Hungarian Notation they used at Prudential for naming columns:

vchCompanyName = company name, varchar
intEmployeeCount = employee count, integer

This seems innocuous enough. Since I didn’t control the database but needed to code against it, I accepted this as Gospel. It was my first interaction with a real database, one that ran on scary Sun Ultra 5 servers at some colo facility on the East Coast, so who was I to disagree? Honestly I was more concerned with getting things done than arguing over a field name. But now I have more time to argue.

Arguments against Hungarian Notation

Convention over configuration is all the rage today. Ruby on Rails programmers claim this to be part of the secret sauce that empowers them to quickly build new services like Basecamp, Blinksale and Twitter. Since many opponents of HN argue that a compiler is your sanity check, it’s especially relevant for untyped languages like PHP and ColdFusion that don’t have such a fallback. HN subtly communicates information to the developer but it can also be programmatically leveraged as I will demonstrate later.

Another common argument against HN is that the editing environment can give you on-demand details of data types or flag incompatible operations based on introspection. Most of the developers I know have migrated to Eclipse + CFEclipse for ColdFusion. While for Java or C the IDE can give you a wealth of information about the code, that support is not available to untyped or dynamically generated languages like ColdFusion which don’t declare variable types.

Perhaps my favorite argument is that HN is not portable since two companies may not implement it in exactly the same way; therefore having no standard is preferable. But this makes no sense! There are changes anytime we switch companies or projects! We also need to learn where the bathrooms are located and the names of our new co-workers; are these critics really suggesting that developers are unable to adapt?

Lastly I have read that using HN locks the code into a particular data type making data model changes more difficult down the road. This might have been true before the advent of search and replace but with today’s IDEs, you can trigger a very accurate system-wide replacement with Regular Expressions in seconds. With the exception of some very large or distributed projects, I simply can’t believe this to be the case any longer. In fact, I would argue that Hungarian Notation makes these kinds of system-wide changes easier because the field and variable names have more specific and unique names making a RegExp more precise (this is the same reason why I never name an iterator variable “i” or “j” – I always use “ii” or “jj” so you can search and/or replace it).

The old arguments against Hungarian Notation just simply don’t make sense in today’s web development environment. Thus, I present to you my top reasons to love Hungarian Notation!

Four Reasons to love Hungarian Notation

1. With no variable typing, IDE introspection or language compiler to fall back upon for PHP, ColdFusion and other web languages, HN subtly communicates valuable information to the developer that helps prevent and identify mistakes.
2. The greatest cost of software is actually the maintenance, assuming you’re not some pump-n-dump consultant who rides from one gig to the next. Hungarian Notation significantly improves maintainability because a developer can return to code six months or six years later and have an immediate handle on what is going on in the code without knowing the intricacies of the data model. These prefixes act like hints, continually reminding us of where we are and what we’re dealing with. It’s built-in documentation that you never have to sit down to write!
3. Prefixes can allow you to catch special situations. I use Transfer ORM against PostgreSQL. One of the great things about postgres are the extensive data types it supports which include things like GIS “points” and UUIDs and timestamp-differential “Intervals”. Problem is, Transfer would throw errors when I accessed an interval column but Hungarian Notation came to the rescue. Since I prefix all interval columns with “inv”, I modified TransferSelecter.cfc starting with:

   default:
   	null = null & "text";

   to handle this special case:

   default:
   if (left(arguments.column, 3) EQ "inv")
   {
   	null = null & "interval";
   }
   else
   {
   	null = null & "text";
   }

   Not the ideal fix but the prefix saved my bacon with a minimal amount of work when I was in the middle of writing my application.

4. No collision with reserved words in SQL or any other language. Consider an e-commerce site: it would surely have an “Order” table and perhaps a “Group” table, both of which are reserved keywords in SQL. You can work around that by making them plural or giving them a more descriptive name like “SiteOrders” but consistently prefixed names like tblLookupOrder will never conflict with reserved words.

Ghidinelli (Hungarian) Notation

There are many interpretations of Hungarian Notation out there but I will share the prefixes and naming conventions I use to paint a picture of a system I have used alone and in teams for over a decade. I don’t claim this to be the way, but rather a way.

My first personal rule is that all prefixes should be three characters. There are two reasons for this – with three characters you will surely have enough combinations to adequately abbreviate the object you are trying to describe. Secondly, it allows you to programmatically check the prefix since it will always be three characters long (see the Transfer example above). Beyond that, I use a combination of what I learned back in 1994 and what sounded good to me as time went by:

Table Naming

• tblLookup* – a normalized lookup table to hold an idea. ex: tblLookupUser, tblLookupOrder.
• tblMap* – a mapping table between typically two lookup tables to describe a relationship. ex: tblMapUserOrders or I have seen others use tblMapUsersToOrders.
• vue* – a view prefix, usually using the same Lookup and Map pieces. ex: vueLookupAttendee.

Column Naming

• boo – boolean
• int – integer
• snt – small integer (int[2])
• tnt – tiny integer (int[1])
• chr – character
• uid – character(35) used for storage of UUIDs which I use as primary keys in many instances.
• vch – varying character
• txt – text or unlimited varying character (depending on platform)
• inv – interval
• num – numeric
• dec – decimal
• mny – money, which may actually be decimal but better describes it as currency
• xml – XML storage for databases that support it like PostgreSQL, Oracle…
• dte – date
• dtm – datetime/timestamp
• rad – radians (may be represented as decimal)
• net – IP address

Application Variable Naming

• arr – array
• str – struct (in coldfusion, object in javascript, etc)
• obj – an instance of a coldfusion component
• int – integer/numeric
• qry – query

I’ve become less strict about the variable naming rules in the past years mostly because with CFCs, I keep my methods short enough to be clear. I may be more strict in using them in the view layer where non-programmers or other users might need to do some work since we can share a key of “what is what”.

Conclusion

At the end of the day, Hungarian Notation does not cost the developer anything but may add value in a variety of circumstances, specifically consistency, maintainability and flexibility. There may be components of these conventions that people don’t like, but they clearly do solve the items laid out above.

These are guidelines I generally use but freely break as needed. I tend to be very strict in the data layer and less strict in the display layer. I’ve been writing my current application now for five years and I can’t imagine wading into some of my old code without these hints – it would take at least twice as long to make simple changes. This is the key reason why I continue to use Hungarian Notation!