How does the verbosity of identifiers affect the performance of a programmer?

Question

I always wondered: Are there any hard facts which would indicate that either shorter or longer identifiers are better?

Example:

clrscr()

opposed to

ClearScreen()

Short identifiers should be faster to read because there are fewer characters but longer identifiers often better resemble natural language and therefore also should be faster to read.

Are there other aspects which suggest either a short or a verbose style?

EDIT: Just to clarify: I didn't ask: "What would you do in this case?". I asked for reasons to prefer one over the other, i.e. this is not a poll question.

Please, if you can, add some reason on why one would prefer one style over the other.

Answer 1

I'd go for clarity over verbosity or brevit.

ClearScreen() 

is easier to parse than

clrscr() 

in my opinion, but

ClearScreenBeforeRerenderingPage() 

is just noise.

Answer 2

Abbreviations put a much greater burden on the reader. They are ambiguous; they are indirect; they are harder to discriminate. They burden the writer, too, for s/he must always be asking, "was that Cmd for Command, or Cmnd... or Cm?". They clash - a given abbreviation rule could produce the same abbreviation for two (or more) different words.

Because they are ambiguous, the reader must take time to think about what word is intended; if the word itself is present, the reader need only think about its meaning.

Because they are indirect, they are analogous to a pointer - just as there's a little processing time consumed by every pointer dereference, there's a little (human) processing time consumed, and additional memory occupied, by every abbreviation.

Answer 3

Certainly .NET developers should be following the .NET Naming Guidelines.

This suggests that the full names should be used, not abbreviations:

Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin.

Answer 4

Personally I like to try a follow the wisdom of Clean Code by Uncle Bob.

To me it suggests that Code should read like prose. By using descriptive names and ensuring that methods have a single responsibility we can write code that accurately describes the programmers intent obviating the need for comments (in most cases).

He goes on to make the observation that when we write code, we often spend 90% of the time reading the surrounding code and dependent code. Therefore by writing code that is inherently readable we can be far more productive in our writing of code.

Answer 5

I remember a talk from Larry Wall some time ago where he talked about the verbosity of identifiers when you have non-native English speakers in your team.

ClearScreenBeforeRerenderingPage()

parses fine if you're a native English speaker. However he suggests (and experience shows) that:

Clear_Screen_Before_Rerendering_Page()

is much better.

The effect is exacerbated when you don't use both upper and lower case.

Answer 6

My basic rule is that every line of code is written only once, but read 10, 100, or 1000 times. According to this, the effort of typing is totally irrelevant. All that counts is the effort to read something.

Of course, this alone still leaves enough room for subjective opinions (is clrscrn readable enough?), but at least is narrows the field somehow.

Answer 7

Please go directly to the relevant chapter of Steve McConnell's "Code Complete" (sanitised Amazon link).

Specifically, chapter 11, "The Power of Variable Names".

Answer 8

My personal preference is to have verbose public identifiers and short private ones.

By public I mean class names, method names, global variables and constants, packages, namespaces - in short anything that can be accessed from a large number of places and by large number of people.

By private I mean local variables, private members, sometimes parameters - stuff that is only accessed from inside limited local scope and by single developer only.

Answer 9

Also consider where it's going to be used, ClearScreen() is likely to appear on its own.
However you cringe when new programmers who have learned that the identifier must be easily readable, produce code like.

 screenCoordinateVertical = gradientOfLine * screenCoordinateHoriontal + screenCoordinateOrigin;

instead of

 y = m*x + C;

Answer 10

Every developer should know how to touch type. Adding a few extra characters is not a productivity issue unless you're a hunt and peck typist.

With that said, I agree with the previous comments about balance. As with so many answers here, "it depends". But I favor verbosity and clarity. Taking out vowels is for old DBAs.

Answer 11

As a programmer I do much more thinking while programming than typing. So the extra time typing a longer identifier is of no relevance. And today my IDE is supporting me, I now have only to type some letters and the IDE let me choose from legal identifiers. So the productivity-argument against longer identifiers is today more invalid than it was a few years ago.

On the other side you gain readability if you choose more meaningful identifiers. Since you will read source-code more often than writing it, this is very important. Another point is, that abbreviations often are ambiguous. So do you abbreviate number as no, or as num? That makes errors more probable, as you choose the wrong identifier.

Answer 12

Always using full words in identifiers also helps to maintain consistency.

With abbreviations there is always the question whether the word was abbreviated, and if yes how.

For example, right now I'm looking at code which has index abbreviated as ndx or idx in various places.

For very local context it is OK to abbreviate, but then I'd use only the first letter of each word to guarantee consistency. E.g. sb for StringBuilder.

Answer 13

I think you'll find precious few hard facts, but lot of opinion on this subject.

The Wikipedia page on this topic links to a paper on a cost/benefit analysis of identifier naming issues (External Links section), but no language I know of bases its official or accepted naming conventions on the basis of a "scientific" study.

Looking at code in a social context, you should follow the naming conventions imposed by:

1. The project
2. The company
3. The programming language

.. in that order.

Answer 14

It's really all about finding a balance between the two, that is easy enough to read while at the same time not overly verbose. Many people have a personal dislike for Java or Win32's elaborate function/class names, but many others dislike very short identifiers as well.

Answer 15

Most modern IDEs (and even older ones) have an auto-complete feature, so it doesn't really take more time to type a long identifier (once it is declared of course). So I'd go for clarity over brevity, it makes the program much easier to read and more self-explaining

Answer 16

Nothing wrong with a short identifier as long as its obvious what it means.

Personally I'd lean toward the latter because i prefer to be verbose (Though i try not to be so verbose as MS and their CoMarshallInterthreadInterfaceInStream function) but as long as your Clear Screen function is not called "F()" I don't see a problem :)

Answer 17

Naming conventions and coding style are often discussed topics.
That said, the naming conventions are always very subjective -- to people and platform.

Bottom line is always -- let things make sense (yes, very subjective).
Wikibook search -- Naming identifiers

Answer 18

Also one has to think of where the identifier is, the well known i as iteration counter is a valid example:

for(int i=0;i<10;i++){
    doSomething();
}

If the context is simple the identifier should reflect this accordingly.

Answer 19

No one has mentioned the negative impact on readability of identifiers that are too long. Once you start making identifiers that are 20, 30, 40 or more characters long you cannot write a reasonable statement on one line of text that is readable. Lines of code should be limited to about 80 characters. Anything longer is impossible to read. That is why newspapers are printed in columns. Even this webpage keeps the text column narrow so that it can be read without having to scan back and forth.