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

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 2

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 3

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 4

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 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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. Because 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 abreviate number as no or as num? That makes errors more probable, as you choose the wrong identifier.

Answer 14

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 15

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 16

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 17

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 18

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.