Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there anything to be gained from short variable names?

Is there anything to be gained memorywise and speedwise by having shorter variable-names in a language like python?

And if so, what kind of situations would it be reasonable to consider this?

Note

I'm in no way advocating short variable names, I'm just wondering, please (re)read the question.

Note 2 Please, I do understand the value of descriptive variable names. I've looked at enough code to prefer descriptive names over shorter names, and understand the value of it. A plain No doesn't really help.

like image 248
Daniel Figueroa Avatar asked Aug 24 '12 09:08

Daniel Figueroa


People also ask

Are short variable names better?

Names to AvoidIt's almost always best to avoid single-letter variable names, which are not unique enough to help the reader associate a meaning with the name. This increases the mental tax on the reader and makes it harder to understand what the program is doing.

Why do programmers use short variable names?

It is an open research issue whether some programmers prefer shorter identifiers because they are easier to type, or think up, than longer identifiers, or because in many situations a longer identifier simply clutters the visible code and provides no perceived additional benefit.

Does variable name length affect performance?

Variable name will have absolutely no influence at runtime, and totally negligible at compile time. But bad names will inevitably lead to bad performance because nobody understand the code and it ends up in a stack of hack one on top of another, making things worse each time.

What is the importance of a variable name?

The variable's name represents what information the variable contains. They are called variables because the represented information can change but the operations on the variable remain the same. In general, a program should be written with "Symbolic" notation, such that a statement is always true symbolically.


2 Answers

No. No. No. No. No.

No.

Use readable names, not short names. The performance difference is absolutely neglegible.


$ python -m timeit "i = 5" "i *= i"
10000000 loops, best of 3: 0.0938 usec per loop

$ python -m timeit "is_there_anything_to_be_gained_from_short_variable_names = 5" "is_there_anything_to_be_gained_from_short_variable_names *= is_there_anything_to_be_gained_from_short_variable_names"
10000000 loops, best of 3: 0.0927 usec per loop

Ironically, when measured on this PC the long variable name was consequently measured ~0.001 usec faster per execution.

like image 62
orlp Avatar answered Sep 22 '22 14:09

orlp


There's a problem with "like python", because not all interpreted languages are the same.

With a purely-interpreted language it would have more of an impact than with one like Python that has a pre-compile step. Strictly this isn't a language difference (you could have one Javascript engine that precompiles, and one that doesn't), but it does affect the answer to this question.

Stretching out "like python" to include every interpreted language, I'd say the answer is "yes, for some of them, at least some of the time". The next question is, "how much".

In 1997 through to early 1998 I was working on some rather complicated javascript code that made use of some of the new features of Netscape Navigator 4 and Internet Explorer 4. This was a humongous javascript file for the time - when the prevalence of dial-up meant that every kilobyte counted in terms of site speed.

For this reason, we used a minimiser script. The main thing this did, was to re-write variables to be shorter (lastHeight becomes a, userSel becmomes b and so on).

Not only did it reduce the download time, but it did also make one of the heavier functions appreciably faster. But only appreciable if you were someone who spent their whole working day looking at nothing else, which pretty much meant me and one other colleague.

So yes, if we put Javascript into the "like python" category as far as interpretation goes, then it can make a difference, under the following conditions:

  1. It was running on Pentium, Pentium Pro and 486s (Pentium II was out then, but we didn't have any). I got a new machine part-way through the project, which meant I went from 133MHz to 166MHz.
  2. It was a rather large piece of nasty looping (most of the script had no appreciable difference).
  3. It was running on a script-engine from 15years ago with none of the improvements in script-engine performance that have been made since.

And it still didn't make that much difference.

We can assume for that, that some other interpreted languages are also affected to a similarly minute degree.

Even in 1997 though, I wouldn't have bothered were it not that it coincidentally gave me another advantage, and I certainly wasn't working on the minimised version.

like image 36
Jon Hanna Avatar answered Sep 21 '22 14:09

Jon Hanna