A modern Hungarian notation

Some discussion has recently popped up on the internet about the use of Hungarian notation. Many software engineers are passionate about conventions, and we know a topic so sensitive can get people worked up!

We, too, would like to share our thoughts about an approach to modern-day Hungarian notation.

Clip from *The Other Guys*
Mark Wahlberg clearly disagrees with us

Background

Let’s refresh our CS theory on what Hungarian notation is again. From Wikipedia:

Hungarian notation is an identifier naming convention in computer programming, in which the name of a variable or function indicates its type or intended use. There are two types of Hungarian notation: Systems Hungarian notation and Apps Hungarian notation.

The differences between the two are:

  • Systems Hungarian notation distinguishes identifiers through a prefix that encodes for the data type, for instance by designating l as a prefix for longs, or i or n for integers.
  • Apps Hungarian notation distinguishes identifiers through their purpose, for instance by designating m as a prefix for private member fields, and s for static fields.

For the interested reader, the Wikipedia article is very elaborate, listing many examples with advantages and disadvantages.

Our opinion at Pixplicity is that Systems Hungarian notation is primarily used for languages with dynamic typing (such as Perl, PHP or JavaScript), and doesn’t have any merits for Java (or Android). Let’s instead focus on Apps Hungarian notation, and specifically for Android.

The discussion

The discussion appears to have originated from a Reddit post on /r/androiddev on January 21st, where Reddit user guillaumeyp points to the Google Java Style Guide. It’s interesting to take note of the naming conventions; Google discourages the use of Hungarian notation altogether. Reddit user alanviverette then points out that it doesn’t reflect Android, but Java style as a whole at Google, and instead references the AOSP style guidelines.

Later that day, Jake Wharton, having followed the Reddit discussion, posted his thoughts on his blog:

Every day new Java code is written for Android apps and libraries which is plagued with an infectious disease: Hungarian notation.

Some others have gone so far as writing guides on marking the notation as errors.

A modern approach for Android

We disagree with Jake on this. There is a place for Hungarian notation!

  • Consider the scope of variables. It’s easy to make a mistake and address the wrong variable, because there may be two with literally the same name: the local var and this.var or MyClass.var, depending on if it’s static or not.
  • Solely relying on the styling and coloring of your IDE is a recipe for mistakes. While it’s likely that all Android developers use Android Studio, a code reviewer cannot see in a snippet in the terminal or an online merge tool what the scope of a variable in the snippet is.
  • In fact, we think it’s a good idea to use the m and s prefix notation, because it’s reassuring to know those fields are private members. Since they’re not exposed outside my class, why does Jake care so much?
  • After all, is littering your code with this. any better?

Let’s take things a step further, though: what about prefixes in general?

We like to keep our code organized for readability, and use prefixes where they clarify the purpose of a variable. Consider this snippet when using Butterknife to inject your views:

@InjectView(R.id.rv_items)
protected RecyclerView mRvItems;
@InjectView(R.id.fab)
protected FloatingActionButton mFab;
@InjectView(R.id.tv_title)
protected TextView mTvTitle;
@InjectView(R.id.bt_details)
protected TextView mBtDetails;

At a glance, wherever in your code, by using mTvTitle it’s apparent that you’re accessing a TextView from a private field. Through naming conventions between the resources and code, it’s evident that the XML layout file uses a similar prefix, tv_. Imagine the confusion if a variable title was used interchangeably for the string to be displayed in a TextView of the same name:

this.title.setText(title);

Eww!

Your team’s style

At the end of the day, whether you like Hungarian notation or not, we at Pixplicity want to emphasize that being consistent is key. Ultimately, it’s a matter of style. There’s no compelling reason on either side of the argument to use or not use prefixes for variables, since after all, it’s simply a naming convention. Instead, be a teammate and adopt your team’s style guidelines, whether or not it matches your own preference!

Share

One comment on “A modern Hungarian notation

  • Jozua Sijsling

    Not needing the this-keyword is nice. But I can see where Jake’s comment is coming from. Some of Square’s most popular open source contributions are compatible with (and used by) both Android and standard Java. Adopting the Hungarian notation just because it’s what AOSP does, doesn’t make sense for such projects. The resulting fragmentation probably causes subtle but frustrating issues – like needing to convert a project from one notation to the other, or explaining to contributors that using Android’s default code style won’t get their pull-request merged. I don’t share Jake’s frustration, but I think I understand somewhat.

Leave a Reply

Your email address will not be published.