James Leigh, in a recent blog post, makes a couple of good comments on the importance of code readability and the presence of redundancy.
The accompanying poll question, however, (which asks if easily readable code is important) begs the deeper question...of course easily readable code is extremely important but the real question is how to achieve it.
For example, using abbreviations in identifier names is a poor way to make the names shorter and more concise.
Abbreviated names suffer several problems including:
1) ambiguity: is 'getReq' short for getRequest, getRequirement, or getRequisition?
2) cognitive burden: abbreviations requires much more mental effort to remember which fragment of a word is being employed. This "ideolexical" design makes the API seem much more complex and daunting than it should.
As an example, is the abbreviation for 'declareDescription' going to be:
3) lack of consistency: even with only one programmer creating the abbreviated identifier names, it seems highly probably that inconsistencies will creep into the naming scheme, making it harder to use.
4) loss of readability and documentation: longer names are often clearer and document the code better than abbreviations (or shorter names).
In these days of IDEs there is little reason not to use longer, clearer, self-documenting names: it is trivial to start a name and then hit the appropriate completion key. Even if you program in a non-IDE (as I do....I use Emacs a lot of the time) the importance of good names as documentation cannot be over-emphasized and is well worth a tiny bit of extra typing.