Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Quit Following Android's Example -Prefixed Naming Is Bad

DZone's Guide to

Quit Following Android's Example -Prefixed Naming Is Bad

The original Android team made a bad decision when making their coding conventions or style guide for the project. Don't make the same mistake.

· Mobile Zone
Free Resource

Launching an app doesn’t need to be daunting. Whether you’re just getting started or need a refresher on mobile app testing best practices, this guide is your resource! Brought to you in partnership with Perfecto

Recently I’ve been working on a couple of Android apps and I’ve noticed all Android examples have all their private fields with these silly 'm'  prefixes. The reason for this is years ago the original Android team made a bad decision when making their coding conventions or style guide for the project, possibly made in 2003 when the project started which is more forgivable.

Unfortunately, I’m seeing these prefixes spill over into open source Android apps and random code examples on Stack Overflow (even when it’s clear the names were not part of copied example code). So now the Android team’s laziness to not overhaul their code style or even to use a different code style for examples is now affecting a lot more than just their own team.

Here’s an example of the insanity from an open source project I bumped into the other day,

protected FSKConfig mConfig;
protected FSKEncoder mEncoder;
protected FSKDecoder mDecoder;

protected AudioTrack mAudioTrack;
protected AudioRecord mRecorder;
protected int mBufferSize = 0;
protected boolean mScrollLock = true;

protected ScrollView mScroll;
protected TextView mTerminal;
protected EditText mInput;


The reason prefixed names are bad is because in the present we all have color highlighting for different kinds of variables along with the auto complete list usually listing the kind of variable next to the name. We don’t need a third place to tell us if something is a member or local variable. This particular third way of telling us also reduces the code readability by unnecessarily  cluttering up our variable names and also has the tendency of mucking with expected auto complete ordering.

IntelliJ's wonderful autocomplete showing us whether something is a local or member variable
IntelliJ’s wonderful autocomplete showing us whether something is a local or member variable making the m in front of mExample redundant.
Slightly canned example of the havoc prefixing can wreck on autocomplete
Slightly canned example of the havoc prefixing can wreck on autocomplete in Sublime 3.


If Android used GOTOs (for non-legitimate reasons) then would you too?

Keep up with the latest DevTest Jargon with the latest Mobile DevTest Dictionary. Brought to you in partnership with Perfecto.

Topics:
agile software ,java ,android

Published at DZone with permission of Maddie Abboud. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}