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.
Mark Wahlberg clearly disagrees with us
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
las a prefix for longs, or
- Apps Hungarian notation distinguishes identifiers through their purpose, for instance by designating
mas a prefix for private member fields, and
sfor static fields.
For the interested reader, the Wikipedia article is very elaborate, listing many examples with advantages and disadvantages.
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
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
sprefix 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
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:
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!