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.
[ Work smarter, not harder -- download the Developers' Survival Guide from InfoWorld for all the tips and trends programmers need to know. | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
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 receive 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.