Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

9 bad programming habits we secretly love

Peter Wayner | Oct. 20, 2015
Breaking the rules can bring a little thrill -- and produce better, more efficient code.

Sure, you could rewrite all of your code to minimize the conversion, but that would take time. Sometimes it’s OK for the code to run an extra minute, hour, day, or even week because rewriting the code would take even more time. Sometimes running up a technical debt like this is cheaper than building it right in the first place.

Sometimes the library isn't proprietary code, but code you wrote yourself long ago. Sometimes it's faster to convert the data one more time than rewrite everything in that library. So you go along and you write yo-yo code. It’s OK -- we’ve all been there.

Programming habit No. 6: Writing your own data structures

One of the standard rules is that a programmer should never write code for storing data after completing the data structures course in their sophomore year. Someone else has already written all of the data structures we'll ever need, and their code has been tested and retested over the years. It’s bundled with the language and it’s probably free. Your code could only have bugs.

But sometimes the data structure libraries are a bit slow. Sometimes they force us into a structure that may be standard but wrong for our code. Sometimes the libraries push us into reconfiguring our data before we use the structure. Sometimes the libraries include belts-and-suspender protections with items like thread locking, and our code doesn’t need them.

When that happens, it's time to write our own data structures. Sometimes it's much, much faster. And sometimes it makes our code much cleaner because we don't include all of the extra code for reformatting the data exactly so.

Programming habit No. 7: Breaking out of loops in the middle

Somewhere along the line, a rule-making group declared that every loop should have an "invariant," which is to say a logical statement that is true throughout the loop. When the invariant is no longer true, the loop ends. It's a good way to think about complex loops, but it leads to crazy prohibitions -- like forbidding us from using a return or a break in the middle of the loop. This is a subset of the rule forbidding goto statements.

This theory is fine, but it usually leads to more complex code. Consider this simple case that scans an array for one entry that passes a test:

while (i<a.length){
   ...
   if (test(a[i]) then return a[i];
   ...
}

The loop invariant lovers would rather we add another boolean variable, call it notFound, and use it like this:

while ((notFound) && (i<a.length){
...
if (test(a[i])) then notFound=false;
...
}

If this boolean is well-named, it’s a great piece of self-documenting code. It may make it easier for everyone to understand. But it’s also added complexity. And it means allocating another local variable and clogging up a register that the compiler may or may not be smart enough to fix.

 

Previous Page  1  2  3  4  5  Next Page 

Sign up for CIO Asia eNewsletters.