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.

He had a point. His edict would make debugging easier. As you stepped through the code, the debugger would step from action to action. It wouldn’t get stuck on one line. It was easier to follow.

But boy did the code get long. The Return key on my keyboard wore out as I kept inserting lines. And I’m sure he bragged about how many lines of code his team was writing.

Alas, sometimes it makes it easier to declare a bunch of variables in one line. Sometimes it’s simpler to put all of the boolean clauses together -- everything is more compact. That means we see more logic on the screen without scrolling. It's easier to read, which means understanding comes faster. It’s that simple.

Programming habit No. 4: Not declaring types

The folks who love typed languages have a point. We write better, more bug-free code when we add clear declarations of the data type of each variable. Pausing a moment to spell out the type helps the compiler flag stupid errors before the code starts to run. It may be a pain, but it helps. It’s a belts-and-suspenders approach to programming that stops bugs.

Times have changed. Many of the newer compilers are smart enough to infer the type by looking at the code. They can work backward and forward through the code until they can be sure that the variable must be a string or an int or something else. And if these inferred types don't line up, then they can raise an error flag too. They don’t need us to type the variables any more.

This means it's now easier to save a few bits by leaving off some of the simplest declarations. The code becomes a bit cleaner, and the reader is usually quite able to guess that the variable named i in a for loop is an integer.

Programming habit No. 5: Yo-yo code

Programmers like to call it "yo-yo code." First the values are stored as strings. Then they're parsed into integers. Then they're converted back to strings. It's terribly inefficient. You can almost feel the CPU struggle under all the wasted load. Smart programmers who write fast code design their architectures to minimize the conversions. Their code runs faster because of their planning.

But believe it or not, sometimes it makes sense. Sometimes you have a whiz-bang library that does a bazillion intelligent things inside its proprietary black box. Sometimes the boss wrote a seven-figure check to license all of the genius inside that black box. If the library wants the data in strings, you give it to the library in strings even if you recently converted it into integers.


Previous Page  1  2  3  4  5  Next Page 

Sign up for Computerworld eNewsletters.