10 bad coding practices that wreck software development projects

The Pareto principle states that 80 percent of outcomes can be attributed to 20 percent of the possible causes of a given event. Also known as the 80-20 rule, it’s relevant to almost every field of human endeavor.

In the field of software development, the principle can be summarized by saying that most problems are caused by a small number of bad coding practices. Eliminate them and your work will be very much easier and more productive.

These 10 coding practices are the worst culprits.

1. Typos in Your Code

These are surprisingly common, and they are maddening because they have nothing to do with your programming skill. Even so, a misspelled variable name or function name can wreak havoc on your code. What’s more, they may not be easy to spot.

What’s the solution? Working in a good integrated development environment (IDE) or even a programmer-specific text editor can reduce spelling errors significantly. Another thing you can do: Deliberately choose variable and function names that are easy to spell and, therefore, easy to spot when they have been misspelled. Avoid words such as receive, which easily be misspelled recieve without being obvious.

2. Failing to Indent or Format Your Code

Indenting and otherwise formatting your code makes it easier to understand at a glance and, therefore, spot mistakes. It also makes it far easier for other people to maintain your code, as it’s presented in a consistent fashion.

If you use an IDE that doesn’t automatically format your code, consider running it through a code beautifier such as Uncrustify, which will format it consistently according to the rules you configure.

3. Failing to Modularize Your Code

It’s good coding practice to write functions that do one thing and one thing only. That helps keep them short and, therefore, easy to understand and maintain. Long functions have many possible paths through them, making them much harder to test.

A good rule of thumb: One function should occupy no more space than a single screen. Another one: If it has 10 or more “if” statements or loops, then it’s too complicated and should be rewritten.

4. Letting Your IDE Lull You Into a False Sense of Security

IDEs and other tools that provide code completion are fantastic for productivity. They suggest variables and other things based on what is in scope, given what you have already typed. But there’s a danger with this type of tool — you can pick something because it looks like what you expect without taking the necessary effort to ensure that it’s exactly what you want. Essentially, the tool does the thinking for you, when you in fact are responsible for making sure that the thinking is right.

There’s a fine line to be drawn, though. Code completion tools can help eliminate errors such as typos and increase productivity, but they can also introduce “code completion” errors if you don’t stay on the ball.

5. Hard-Coding Passwords

It’s tempting to hard-code a secret account and password so you can get into your system later. You know you shouldn’t do this — yes, it’s highly convenient, but it’s also highly convenient for anyone who gets access to the source code.

The real problem is that a hardcoded password will eventually become more widely known that you had intended. That makes it a huge security risk, not to mention a highly inconvenient fix.

6. Failing to Use Good Encryption to Protect Data

Sensitive data needs to be encrypted as it travels over the network, because it’s vulnerable to interception when it does so. It’s not just a good idea; it’s a regulatory requirement, if not the law.

That means sending data in the clear is a “no no.” It also rules out using your own encryption or obfuscation scheme as well. Writing your own secure encryption system is hard — just look at what happened with WEP — so use a proven industry standard encryption library and use it correctly.

7. Optimizing Code Prematurely

Legendary programmer Donald Knuth once said, “Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered.”

Being clever with your code may make it run infinitesimally faster, but it makes it far harder to debug and maintain. A better strategy: Write your code clearly, then get to work in any parts that really need optimizing in order to improve performance.

8. Failing to Think Ahead

What’s your project for, how much will it be expected to scale, how many users will it have and how fast must it run? The answers to these questions may not be available — but if you fail to make estimates, then how can you choose a suitable framework for developing the application that will be able to meet these requirements?

Twitter provides a good example of the problems you encounter if you underestimate future requirements. Twitter had to abandon Ruby on Rails and rewrite much of its code using Scala and other technologies because the Ruby code, as originally architected, simply couldn’t scale to keep up with Twitter’s fast-growing user base.

9. Adding People to Make Up for Lost Time

Almost every software project falls behind schedule. Adding people to the project to get it back on track sounds like a good idea in theory, but it’s a common mistake. In fact, adding new people to a project is almost always results in a drop in overall productivity.

10. Using Known Bad Time Estimates

At the same time, it’s important to avoid the temptation to imagine that you’ll catch up with your schedule later without adding people to the project. If you fall behind schedule, it’s because your time estimates were wrong. That means you need to make a new estimate of the length of the project, not blindly stick to an estimate that has already been proven wrong.