Agreed. Short names seem like their optimizing for typing speed, rather than ease of readability. If it's true that code will be read many times more than it is written, then descriptive variable names are the answer.
DescriptiveVariableNameUser thinks DecriptiveVariablName is great. DescriptiveVariableName constantly reminds DescriptiveVariableNameUser the DescriptiveVariableNameMeaning of DescriptiveVariableName, so DescriptiveVariableNameUser never forgets descriptiveVariableNameMeaning.
The only way DescriptiveVariableName could me made for meaningful is if DescriptiveVariableNameUser declare s DescriltiveVariableName's type (DescriptiveVariable) every time DesriptiveVariableNameUser accesses (DescriptiveVariable) DescrptiveVariableName.
Of course, knowing when to use an extremely descriptive name is half of the battle. Having a good aesthetic sense as a programmer is crucial. As a general rule, if I can see the entire lifetime of a variable in my field of view, I'll go for short/terse variable names (loop control, temp values, etc). Or if the method name is descriptive, and the code in the method is fairly short, I won't need to repeat myself in the variable names. Good sense is key.
Also, the names used in the article show a very poor aesthetic sense. Names like that are screaming out as needing a refactor. Having a condition in your method name is a code smell. Your methods (read: api) should be abstracted as discreet actions, and the code that calls it should perform control flow.
Very good point: long variable names make it harder to spot when they've been mistyped. Even worse, some long variables become other long variables when mistyped in just the right characters.
On the other hand, in long variable names, the excess of characters provides redundancy, which makes it easier to error-correct. The parent post is riddled with errors that would halt a compiler, but many humans would not even notice them.
