What is Hungarian Notation?
For those not familiar with Hungarian Notation, it is a naming convention that incorporates an item's datatype, intended use, or other metainformation into the item name. Many people have a narrow understanding of Hungarian, and discourage its use. But as you will see, Hungarian is more than "strName", and is not going away any time soon.
Pre-History
Hungarian Notation goes back to the dawn of computing, and formal definitions have been around since the 80's. It first became popular for managing typing in languages that were not syntactically typed, and when simple editors, not informative IDE's, were the tools we had.
In languages like C, we can be explicit about variable types with declarations like
int x = 0;
string y = "Hello";
Languages like Basic don't allow explicit typing, and instead use keywords like "let" and "var" for declarations.
let x = 0
var y = "Hello"
Depending on the language, setting x = y could produce an error, or succeed with results like x becoming 'H', or 72 (ASCII code for H).
Early Days
Developers implemented one of the earliest forms of "type-safety" by post-fixing '$' to string variables. This was helpful in the days when there were only two datatypes (number and string), and interpreters and compilers couldn't enforce this.
let x = 0
let y$ = "Hello"
For consistancy, the suffix % was also used in some areas to indicate a number. As languages matured and additional datatypes became available, another approach was needed. The earliest form of what would become Hungarian built on the post-fix approach. This was not a stylistic choice, many preferred a type-first approach, but a technical constraint of the BASIC language. The BASIC language was becoming the most popular general purpose computing language around that time.
Early versions of Basic only supported two-character variable names. Though later, versions allowed eight character names, only the first two were used internally - "so" and "some" were the same variable. Adopting the [type] [name] order used in declaration-typed languages like C and FORTRAN ( e.g., string :: y) was not possible - strX and strY were the same variable internally - st.
The remaining six characters were, I suppose, the first syntactic sugar - helpful for programmers, but meaningless to the computer. Approaches to using the remaining six characters helped give birth to two other eventually pervasive programming concepts - Hungarian Notation and Metadata.
Many schools of thought developed around how to use these six "extraneous" characters. They can be broken into three main groups - what it is, what type it is, and how it is used. The "what it is" school is basically clear naming - using the extra room to clarify the "real-world" name of the item. A person name goes from "na" to "name". The "type-of" approach uses the room to indicate internal storage type. Name is a string, so - "nastr". The "how-used" had many variations. Some that persist in some forms today are mutability and scope. The constant "name" might be "nacon", or a local variable might be "naloc". This would evolve into things like visibility for variables (i.e., _name for a private variable).
Formalization
Jumping forward many years, the size limitation on variable names had gone away. Clear naming was just part of sound programming practices. Meta-Naming approaches had moved towards the more C-like prefixed and type based approach - strName would be the ordinary form of the example above. Intent based naming had not been abandoned, but was losing favor. As was post-fixing. The advent of object-oriented programming brought both back to some extent. In a Cartesian system, we might find the x and y coordinates of a point named fltXPoint and fltYPoint. Or to indicate the name of a function that returns an integer, we may see intSumFn.
Much of the work around formalizing these conventions took place in the late 80's. The most recognized names in this work are Charles Petzold, Doug Klunder, and Charles Simonyi. Of these, Simonyi had the most influence, if for no other reason that the name Hungarian derived from the Hungarian heritage of Simonyi. Simonyi's influence went well beyond contributing to the name though. Simonyi was the father of MS Word and Office, and standardized the use of Hungarian Notion across that group, which eventually spread across all of Microsoft. The Standard Form of Hungarian Notation was defined as having three parts - Tag, Base Name, and Qualifier.
Formalization produced two primary flavors of Hungarian - Apps Hungarian and Systems Hungarian. These differed primarily in the way the Tag is used. Apps Hungarian utilizes the storage-type prefix (strName) for the Tag. Systems Hungarian was more use driven, with two common approaches - colorBackground (system use) or m_Background (scope). M stands for "member", commonly used to indicate a private variable or backing variable for a property. The m_ was so common is code that many dropped the m, and simply used _. Qualifiers were used to extend the semantics. Commonly used qualifiers were things like min, max, first, and last - intRangeMin and intRangeMax. A alternative form used the older "meta-type qualifier" approach - intBackgroundColor.
Visual Basic
As languages advanced, most languages supported declaring type with the variable. IDE's provided better visibility into types (Intellisense), and made Apps Hungarian less useful. But the popularity of Visual Basic increased the Hungarian overall. The structure of Visual Basic often links a "visual" form file with a backing code file. The code file commonly responded to events raised by "controls" in form. It became a standard approach to use Hungarian to maintain linkage between these files by prefixing a variable with the control type. Most of us are familiar with btn_Accept or txt_FirstName. Qualifiers became associated with events. The event handler for a button click event was named btn_Accept_OnClick(). The BaseName "Accept" and the Tag "btn, and the Qualifier "Click" (OnClick).
The GUI approach to building forms in VB (and ASP) was backed by code generators. To maintain semantic naming and avoid potential name collisions, it was common for the generators to append the control type to the control name. A textbox for First Name would receive the name FirstNameTextBox, to avoid coliding with a user variable txt_FirstName. A button might be AcceptButton. This form is Systems Hungarian in reverse, and was named "Reverse Hungarian".
So, What is Hungarian?
We can see that Hungarian Notation is not just the one form "strName", - typeVariable, or even [Tag][BaseName]. Any name that that uses variations of [Tag][BaseName][Qualifier], including reversed [Qualifier][BaseName][Tag] is a Hungarian name. And, while a common form (Apps Hungarian) uses storage types (e.g., int) for Tags, others (System Hungarian) don't. An online dictionary gives this definition for Hungarian Notation:
"Hungarian notation is an identifier naming convention in computer programming, in which the name of a variable or function indicates its intention or kind, and in some dialects its type."
Contrast this definition to what many people might say when asked to define Hungarian Notation. Maybe -
"Hungarian Notation is prefixing a variable name with an abbreviation for its datatype."
The first defines Hungarian Notation, the second only one flavor of Apps Hungarian that uses Tag and BaseName, and omits Qualifiers.
Hungarian Today
Fast forward to today. Do you do DI and name your local injected variables something like "_context"? Hungarian. IInterface, iInterface, or i_Interface? Hungarian. Do you use ASP.Net MVC? The entire MVC convention-based system is Hungarian. Are your controllers named SomethingController? Hungarian (Reverse). Async? If you append your async methods with Async, you are using a Hungarian Qualifier. Apps Hungarian (e.g., strName) provides little value in modern programming, and I think its use should be discouraged. But if we eliminate the use of all Hungarian, what are the options? Hungarian has reigned as our naming convention since the 80's, and will continue to be our standard for the foreseeable future. Hungarian is Dead, Long Live Hungarian!
