Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Is there any scientific evidence that the human brain can read and understand fully written variable names better/faster than abbreviated ones?

Like

PersistenceManager persistenceManager;

in contrast to

PersistenceManager pm;

I have the impression that I get a better grasp of code that does not use abbreviations, even if the abbreviations would have been commonly used throughout the codebase. Can this individual feeling be backed up by any studies?

share|improve this question

migrated from stackoverflow.com Jan 3 '11 at 15:35

This question came from our site for professional and enthusiast programmers.

3  
Could be a question for programmers.stackexchange.com –  miku Jan 3 '11 at 14:29
2  
I have the impression that I get a better grasp of code that fits on my screen without line-wrapping, and where the structure of the code is not distorted by huge identifiers. I would like to know if there was any real evidence though: imagine it's quite a difficult sort of thing to measure. –  James Jan 3 '11 at 14:42
1  
This question is not subjective or argumentative. There is at least one factual, non-subjective answer, below. The migration to programmers.stackexchange.com seems inappropriate. –  Andy Thomas-Cramer Jan 3 '11 at 17:17
2  
Finally a very good migrated question! :) –  bigown Jan 3 '11 at 20:01
1  
It's not how much you can understand your own code, it's how much anybody can understand your code. How you abbreviate things isn't necessarily intuitive to anybody else (or even yourself in the distant future). If you spell it out, you can guarantee that the variable name's meaning won't get lost in translation. –  Evan Plaice Mar 26 '11 at 17:27

9 Answers 9

up vote 40 down vote accepted

In "Code Complete," Steve McConnell cites one study from 1990:

Gorla, Benander and Benander found that the effort required to debug a program was minimized when variables had names that averaged 10 to 16 characters ... Programs with names averaging 8 to 20 characters were almost as easy to debug. The guideline doesn't mean that you should try to make all of your variable names 9 to 15 or 10 to 16 characters long. It does mean that if you look over your code and see many names that are shorter, you should check to be sure that the names are as clear as they need to be.

Gorla, N., A.C. Benander, and B.A. Benander. 1990. "Debugging effort estimation using software metrics." IEEE Transactions on Software Engineering SE-16, no. 2 (Februrary): 223-31.

share|improve this answer
9  
+1 on Code Complete. Agreed, and as auto-complete is almost always available in our IDEs. I don't see much reason why we shouldn't use longer descriptive name other than cryptic short form e.g. pm. (unless it have a really short lifespan) –  Zekta Chan Jan 3 '11 at 15:53
    
I would be very, very hesitant to put much weight on any paper that claimed to find anything by examining software metrics, since almost all of the metrics out there correlate very strongly with plain, vanilla, raw SLOC, and EVERYONE knows that shorter programs are easier to write, debug, and maintain than longer ones. –  John R. Strohm Mar 26 '11 at 16:31
    
@ZektaChan beyond a certain point really long names start to cause problems for word wrapping at reasonable line lengths. Devils Advocacy: AbcdefghijklmnopqrstuvwxyzType abcdefghijklmnopqrstuvwxyz = new AbcdefghijklmnopqrstuvwxyzType(); QwertyuiopasdfghjklzxcvbnmType wwertyuiopasdfghjklzxcvbnm = new QwertyuiopasdfghjklzxcvbnmType(); abcdefghijklmnopqrstuvwxyzAndQwertyuiopasdfghjklzxcvbnmFrobber.Frobinate(abcdefg‌​hijklmnopqrstuvwxyz, qwertyuiopasdfghjklzxcvbnm); –  Dan Neely Aug 17 '12 at 20:58
    
Theonlyproblemwithlongvariablenamesiswhenpeopleforgettoincludespacesbetweeneachw‌​ord. And_of_course_we_put_spaces_in_variables_using_underscores. Your choice. –  tchrist Feb 12 '13 at 1:15

I haven't ever seen any scientific evidence on this but, abbreviations can be very ambiguous and can be interpreted differently by different users in different contexts.

Even your simple example above gives a clear indication of this.

PersistenceManager pm;

Whilst pm may seem like an obvious choice to you, I might associate this with pm as in relation to a time (a more common usage of pm).

share|improve this answer
1  
One that took me for a spin when I first saw it: MT as a shorthand for "empty". –  Xiong Chiamiov Jan 4 '11 at 1:13
1  
"mt" is pun rather than an abbreviation. –  Stephen C Mar 26 '11 at 4:31

Not scientific but... perhaps an "expert opinion".:

I hate variable abbreviations, and so should every one of you (even the lazy ones).

It is horrible when you are trying to read a block of code and you have 10 of these in a tangled mess. Conversely, when you use self-explanatory and meaningful variable names it is like the code talks to you, and you can even save the bloody comments (for the lazy ones).

share|improve this answer
    
For clarification, do you dislike more 'idiomatic' abbreviations, such as avrTime for average time? –  Michael K Jan 3 '11 at 15:51
1  
I'd deslike that one more because it doesn't carry a standard abbreviation (avg), but I'd guess avgTime would be ok... but I still deslike it. –  dukeofgaming Jan 3 '11 at 16:01
2  
In an algorithms class I took, a relatively large percentage of the lecture was dedicated to renaming variables in our book. When a became unsortedElements, it's amazing how much easier it was to grasp what the hell was going on. Damn mathematicians. –  Xiong Chiamiov Jan 4 '11 at 1:15

Names should be meaningful and descriptive; if you can express that meaning and description in one or two characters, great. After all, almost everyone should know what pi means, especially in a mathematical context.

Beyond that, though, longer names come in much handier. For example, a name like propertyEditor gives me a much better idea of what purpose the object serves than a name like pe.

share|improve this answer

From Wikipedia: Short-term memory at http://en.wikipedia.org/wiki/Short-term_memory

Short-term memory (or "primary" or "active memory") is the capacity for holding a small amount of information in mind in an active, readily available state for a short period of time. The duration of short-term memory (when rehearsal or active maintenance is prevented) is believed to be in the order of seconds. Estimates of short-term memory capacity are 7±2 units...

A long variable name like persistenceManager, especially when the variable is the same as the class with the exception of the first letter, uses one short term memory slot.

A short variable name like pm uses two short term memory slots. One for the class and one for the variable.

With other things being equal, using variable names that are similar enough to the class names aids short term menory, and thus understanding of the program.

share|improve this answer

I think the question that should be asked here is not why use long names, but why use short ones?

Short names are faster to type, but code is "write once, read many times". A programmer spends vastly more time reading code, than writing it. And I am not just talking about code reviews. Every time you look up the definition of a class, or when you try to remember or figure out what a function does, or when you are trying to find a bug, you are reading code. The easier you can make reading code, the more productive you will be.

Long descriptive variable names make reading code easier, while cryptic ambiguous abbreviations make reading code harder, resulting in longer development time, and higher probability of bugs.

Short abbreviated variable names make typing them easier, but the time you save on typing is a tiny fraction of the time you lose reading the code afterward. And if you think of the time you are going to spend debugging your code, because you have long forgotten what pm actually means, and you have used it incorrectly as a result, then you will see that abbreviated names should be avoided at all cost.

share|improve this answer
    
Even if code will be read more often than it is written, it takes less time to read a short name than a long one. If the short name would require that the programmer spend significant time trying to ascertain its meaning, extra time spent deciphering time may swamp the reduction in time spent reading, but abbreviations which don't require extra time to decipher are a 'win' all 'round. –  supercat Jan 18 at 18:29
1  
Actually reading full words is significantly faster than reading abbreviations and acronyms and other arbitrarily short, contrived names. This is because the brain works by seeing the first and last letter of any given word and inferring the word without having to see each letter. Your brain sees the familiar pattern and then derives the word in your head, but with contrived names and made-up ayryonyms, your brain can't perform this optimization. There are numerous published studies on this topic. –  Jonathan Oliver Mar 19 at 2:35

The code I currently maintain is littered with loops over arrays. This is the only place I can imagine where short names may be better, because if the loop indices have short enough names, the whole for (...) { line will be easier to recognize as a 'loop over the whole array'. The condition is that the only place where the loop index is used is on the first line of the loop body, to put the current element in a local variable.

I'm pushing for "Tell, don't ask", and use of algorithms (in the C++ STL sense) rather than hand-coded, but it will take time...

share|improve this answer

I think it depends on both the person, and the application arena. Personally, for the sort of stuff I do, the correspondence with algebra is most important. My brain can not do algebra on long variable names, I literally have to translate to short names to understand it. I've always felt he best way to do it is to maintain a glossery for any nontrivial variable, which describes their usage, that way you can have both readable algebra, and the ability to determine what everything means. In the domains I work in, there is usually considerable algebra. Statements which don't fit on a single source line are hard to understand. For other sorts of code, for instance say flags for obcure things then long names are good, for instance: if(flg7)proceedure(a); Is hard to understand, where if(floating_point_error_flag) log_error_and_terminate(); would be self explanatory. So even in a single application, there are places for long names, and places where short names are best.

share|improve this answer

My opinion is that if short variable names are a problem then variables are probably being misused.

Look at mathematicians. They use short variable names all the time and I wouldn't say that is confusing.

The problem arises when a variable is used all over the place or you have methods more than a couple of lines long.

I never use class level variables within the class itself except for holding the value. In all other places I use Properties (.net) or setters and getters (for classes that don't have properties). If they are only used in the class then they are private. And these things are well named.

In methods if you actually need more than a couple of variables then you should probably be refactoring them into much smaller methods.

So I think if variable names are a problem (and they aren't just silly like var1, var2 etc) then you probably have bigger problems.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.