12 programming mistakes to avoid

A car magazine once declared that a car has "character" if it takes 15 minutes to explain its idiosyncrasies before it can be loaned to a friend. By that standard, every piece of software has character -- all too often, right out of the box.

Most programming "peculiarities" are unique to a particular context, rendering them highly obscure. Websites that deliver XML data, for example, may not have been coded to tell the browser to expect XML data, causing all functions to fall apart until the correct value fills the field.

[ Also on InfoWorld: Find out which 7 programming languages are on the rise in today's enterprise. | Keep up on key application development insights with the Fatal Exception blog and Developer World newsletter. ]

But certain programming practices send the majority of developers reaching for their hair upon opening a file that has been exhibiting too much "character." Spend some time in a bar near any tech company, and you'll hear the howls: Why did the programmer use that antiquated structure? Where was the mechanism for defending against attacks from the Web? Wasn't any thought given to what a noob would do with the program?

Creatures of habit, we developers seem locked into certain failure modes that can't be avoided, such is the frequency with which we fall prey to a particular poor programming practice.

Below you will find the most common programming pitfalls, each of which is accompanied by its opposing pair, lending further proof that programming may in fact be transforming into an art -- one that requires a skilled hand and a creative mind to achieve a happy medium between problematic extremes.

Programming mistake No. 1: Playing it fast and loose

Failing to shore up the basics is the easiest way to undercut your code. Often this means overlooking how arbitrary user behavior will affect your program. Will the input of a zero find its way into a division operation? Will submitted text be the right length? Have date formats been vetted? Is the username verified against the database? Mistakes in the smallest places cause software to fail.

The worst part about sloppy programming is that advances in language design aimed to fix these problems don't do their job. Take the latest version of Java, which tries to make null-pointer checking easier by offering shorthand syntax for the endless pointer testing. Just adding a question mark to each method invocation automatically includes a test for null pointers, replacing a rat's nest of if-then statements, such as:

<code> public String getPostcode(Person person) { String ans= null; if (person != null) { Name nm= person.getName(); if (nm!= null) { ans= nm.getPostcode(); } } return ans } </code>

With this:

<code> public String getFirstName(Person person) { return person?.getName()?.getGivenName(); } </code>

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.

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.

Mistake No. 3: Not simplifying control

Too often, developers invite disaster by not simplifying control over tasks in their code.

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.

1 2 3 4 5 Page 1
Page 1 of 5
Microsoft OneDrive cheat sheet
  
Shop Tech Products at Amazon