B669: Personalized Data Mining and Mapping
Good Ways To Write Bad Code

 
* Don't document everything you decide, especially anything complicated or unusual.
 
* Use short, abbreviated, misleading, or meaningless variable, method, class, and package names.
 
* Don't use consistent and expansive layout.
 
* Don't indicate scopes consistently.
 
* Overload your methods with way too many arguments.
 
* Make your methods do too much.
 
* Give your classes too much to do.

Writing good code is hard work. It takes a lot of practice and enormous attention to detail. Learn to be dissatisfied with whatever code you produce on your first try; no matter how experienced you are, it is always possible to improve.

Our task as professional codesmiths is not to produce code the compiler can understand; that's trivial---the compiler will always tell us if it doesn't understand something. The hard thing is to produce code that another programmer (or we ourselves a few weeks or months into the future) can understand and modify easily because

no good program is ever finished,
the best way to make a lovely, safe, cozy nest for bugs is to produce unreadable code for them to hide in.

Think about the first piece of code. It wasn't wrong was it?---the compiler could understand it and it did indeed do what was required. The problem wasn't even that it was unnecessarily inefficient (although it was). The problem was that it was badly written compared to the second piece of code. Anything that is hard to understand effortlessly is badly written.

Here's the list again, this time with some explanatory background:

Don't document everything you decide, especially anything complicated or unusual.

Every decision you make as you design and write your code should be put in right there in the code for all to see (particularly for you yourself to see). Also, you should write documentation as you code. This helps you produce correct documentation and produce correct code.
 
Use short, abbreviated, misleading, or meaningless variable, method, class, and package names.

The shorter and more meaningless the identifier, the harder the code is to understand a few months later. Even standard abbreviations should be avoided, unless they're perfectly transparent like num and temp, and even then it's best to not use them at all. Write everything out.
 
Don't use consistent and expansive layout.

Skimping on newlines to separate blocks of code or methods and not using spaces around operators and assignments is a good way to befuddle your user and distract attention away from the logical structure of your code. It's even worse to use spacing sometimes but not other times because your reader then thinks that there's something important that was missed.
 
Don't indicate scopes consistently.

The human eye sees the indentation you use much more quickly and easily than the braces you use. The compiler doesn't care, but your readers do. Mixing tabs and spaces is another good way to annoy and confuse your readers if their tab settings happen not to be your tab settings. Use tabs consistently; don't mix them with variable numbers of spaces. Just because it looks good in emacs (or whatever your development environment is) doesn't make it universal.
 
Overload your methods with way too many arguments.

The third piece of code has 11 arguments! This is at least 5 too many. We can only remember so much detail and more than 3 to 5 things confuse us. Worse, if a method is actually using 11 arguments (or even 7) it's probably doing more than one thing---a big no-no. Finally, even if you're forced to use that many arguments once in a while (no rule is unbreakable) the arguments should be grouped to show what's related to what.
 
Make your methods do too much.

A method that is longer than a page is probably far too long. Methods should be anywhere between one line and, say, 20 lines or so. If you can't see the whole thing on a (short) page you probably can't remember all the steps the method takes to accomplish its function---which means it probably has bugs already.
 
Give your classes too much to do.

A class should have one main objective in life and one only. Don't make it slice and dice and do windows too.