Autor: Codenga 10.01.2023

Hungarian notation is a naming convention for variables in programming. Every named object is prefixed with a letter describing its data type.

As you may know, there are several ways of naming things in programming. Some people prefer to use camelCase. Others prefer to use PascalCase. There is also a snake-case and more. Hungarian Notation is simply another approach to naming things like variables. Nowadays, it is considered to be pretty outdated, although you can still find it in some legacy code.

A Hungarian coding style

You may be wondering, why do we call this kind of notation a Hungarian Notation Notation? It was invented by Charles Simonyi - a Hungarian working at Microsoft. He managed to invent and promote this kind of notation and the name simply stuck.

Let’s start with some examples

Take a look at an example:

iNumber

Here the ‘i’ means that the variable is of the integer type. Another example:

sName

The ‘s’ prefix tells us that the variable stores the data of a string type.

There are multiple variations of this notation:.

iNumber
i_Number
i_number

No matter which version is used, the idea is generally the same: a prefix describing a data type + the actual name of the variable.

What about more complex names? What to do when the name consists of several words? Here is a most common approach:.

strUserName

We start with a prefix and the rest of the name uses an ordinary PascalCase.

It’s not only about data types

There are two different types of Hungarian Notations: Systems Hungarian and Apps Hungarian. The first one uses prefixes to describe data types. And you have already seen some examples.

The second one uses prefixes to describe the purpose of the variable or its behavior. Here are some examples:

unName

The above variable is supposed to store “unsafe” (hence: un) strings.

btnSubmit

The above variable references some kind of button object (hence: btn). That approach, honestly speaking, has some merits - it allows us to quickly guess the purpose of the variable. It can be useful especially for code that deals with UI. Some front-end developers, working with HTML/CSS code prefer to name classes this way. It can be a pretty sound approach for this kind of work.

Is Hungarian Notation still relevant?

Generally speaking, Hungarian Notation has fallen out of favor. Especially its variant known as Systems Hungarian. In theory it offered some advantages, allowing us to quickly infer data type just looking at the prefixes. But modern development practices have made this notation redundant.

• In languages with strict type checking, it is a compiler that is responsible for checking if the variable has been assigned a correct data type.
• Modern IDE (Integrated Development Environments) are great at checking data types “on the fly”. They can warn you if you try to assign an incompatible data type.
• You shouldn’t rely on the name alone if you want to be sure that the variable has been assigned a correct data type. People will always try to use your code in a way you have never intended. Adding a prefix does nothing to prevent the bugs caused by straight incompetence.

Today, System Hungarian can be found mostly in the legacy code. New software projects are barely started with this kind of notation.

Back in the day, it was a pretty common way of naming things in the Windows apps. Numerous apps were coded with the variables and objects named according to System Hungarian principles. Nowadays, Microsoft actively discourages the Hungarian Notation. Take a look at those coding guidelines:

https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/general-naming-conventions?redirectedfrom=MSDN.

This sentence makes it pretty clear: “DO NOT use Hungarian notation”.

Apps Hungarian has some merits

When it comes to Apps Hungarian, the story is slightly different. It still has some uses in UI related code. Remember the example: btnSubmit? That is the kind of code we are speaking about. That way of naming things can be useful eg. for naming HTML attributes or CSS selectors. It can be a nice way to describe the purpose or the behavior of a given UI element.