In the end, however, such syntax improvements can only prevent code from crashing, not ensure that it's useful. After all, it doesn't eliminate the root of the problem: the proliferation of null values due to fast and loose programming.
Programming mistake No. 2: Overcommitting to details
On the flip side, overly buttoned-up software can slow to a crawl. Checking a few null pointers may not make much difference, but some software is written to be like an obsessive-compulsive who must check that the doors are locked again and again so that sleep never comes.
Relentless devotion to detail can even lock up software if the obsessive checking requires communicating with a distant website over the network. I have several packages that slow to a crawl if I fire them up on a laptop without a Wi-Fi connection because they're frantically trying to phone home to see if a new version might be available. The Wi-Fi LED flickers, and the software hangs, constantly looking for a hotspot that isn't there.
The challenge is to design the layers of code to check the data when it first appears, but this is much easier said than done. If multiple developers work on a library or even if only one does all of the coding, it's difficult to remember whether and when the pointer was checked.
Mike Subelsky, one of the co-founders at OtherInBox.com, is a keen advocate of there being one and only one place in the code for each job. If there are two places, odds are someone will change one but not the other. If there are more than two, the odds get even worse that someone will fail to keep them all working in the same way.
"Having worked on one code base for three-plus years, my biggest regret is not making the code more modular," Subelsky says. "I've learned the hard way why the Single Responsibility Principle is so important. I adhere to it strongly in new code, and it's the first thing I attack when refactoring the old code."
Subelsky, as you may surmise, is a Ruby on Rails programmer. The framework encourages lean code by assuming most of the structure of the software will fall into well-known patterns, a philosophy that Rails programmers often summarize as "convention not configuration." The software assumes that if someone creates an object of type
Name with two fields
last, then it should immediately create a database table called
Name with two columns,
last. The names are specified in only one place, avoiding any problems that might come if someone fails to keep all of the layers of configuration in sync.
Programming mistake No. 4: Delegating too much to frameworks
Sometimes the magic tools lead only to confusion. By abstracting functionality and assuming what we want, frameworks can all too often leave developers at a loss for what's gone wrong in their code.
G. Blake Meike, a programmer based near Seattle, is one of many developers who finds over-reliance on automated tools such as Ruby on Rails a hindrance when it comes to producing clean code.
"Convention, by definition, is something outside the code," Meike says. "Unless you know Ruby on Rails' rules for turning a URL into a method call, for instance, there is no way, at all, that you will ever figure out what actually happens in response to a query."
He finds that reading the code often means keeping a manual close by to decipher what the code is doing behind his back.