I forgot to mention that the final article in the 4-part series written by Randy Kahle and me was published a few weeks ago on TheServerSide.com:
A RESTful Core for Web-like Application Flexibility - Part 4
The final article contains links back to the previous articles in the series. Just scroll down the the References section at the very bottom of the article.
Monday, October 20, 2008
Abbreviations and Code Readability
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:
declareDescript,
declareDescrip,
declareDescr,
declareDesc,
declDescrip,
declDescr,
OR
declDesc?
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.
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:
declareDescript,
declareDescrip,
declareDescr,
declareDesc,
declDescrip,
declDescr,
OR
declDesc?
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.
Thursday, October 9, 2008
Lisp turns 50 this month
"In October 1958, John McCarthy published one in a series of reports about his then ongoing effort for designing a new programming language that would be especially suited for achieving artificial intelligence. That report was the first one to use the name LISP for this new programming language. 50 years later, Lisp is still in use. This year we are celebrating Lisp's 50th birthday."
-from the Lisp50@OOPSLA web page
Subscribe to:
Posts (Atom)
