When can I get away with using short variable names?

330 views Asked by At

I often find that people stress using variable names that appropriately and accurately describe what the variable is trying to convey. This is also often very hard to do in a word or two. I find it true that though longer names are typically more accepted, they often lead to code that is even less readable because of mere clutter. I find that once I understand what a variable conveys, the name is merely an alias for that understanding, and that the name itself does not necessarily make a difference. In that case, I would personally almost always prefer shorter names to longer ones.

Is it ever appropriate to use short variable names? Is it acceptable to use names that aren't necessarily understood without looking at the rest of the algorithm or class, but perhaps which are commented at declaration of the variable or beginning of the algorithm? Or is it generally always preferable to have longer names that immediately and definitively convey meaning?

4

There are 4 answers

1
Pete Stensønes On BEST ANSWER

For me short (read cryptic) names are palatable in only 1 place; index variables in for or foreach loops.

I think this is only really because of years of exposure to the for index variables as i, j, k etc... and that generally because the loop bodies are short enough to see the use and declaration in the same page.

On the whole, just spend a little time making a meaningful name for the context and just use that!

0
Sergii Shevchyk On

The longer scope variable has - the longer and more descriptive name it should have


Short scope

List<String> result = new ArrayList<String>();
for(String c: cities){
    if(c.contains("CO")){
        result.add(c);
    }    
}

It's clear what c means. Due to short c scope you can quickly get what it is.

Long scope

Let's have a look at HashSet implementation of clone method:

private transient HashMap<E,Object> map;
...

public Object clone() {
        try {
            HashSet<E> newSet = (HashSet<E>) super.clone();
            newSet.map = (HashMap<E, Object>) map.clone();
            return newSet;
        } catch (CloneNotSupportedException e) {
            throw new InternalError();
        }
    } 

If map would be named m would it be easy to understand what m is(without looking into m declaration)?

1
Iwo Kucharski On

Is it acceptable to use names that aren't necessarily understood without looking at the rest of the algorithm or class, but perhaps which are commented at declaration of the variable or beginning of the algorithm?

I'm reading Clean Code now and according to this book (which is a good reference in my opinion) commented code is bad code. You should only use comments where it's necessary. Good code comments itself, so I think if longer names for variables are describing what do you want to achieve in your algorithm - use them.

0
sorencito On

Names should be as long or short as their scope - citing Uncle Bob freely and from memory. So, in loops keep it short, in class scoped variables be verbose. Particularly in APIs names should be intuitive and, moreover, consistent with the rest!

Don't comment large scope variables with their meaning and abbreviate them. This causes steady translation effort by the reader.