Ten Programming Commandments


1. Thou shalt write correct and maintainable code.

When writing code your priority should be to write correct and maintainable code. If your code is not according to the specifications it is useless. Also, your code must be easily understandable by other programmers, must follow coding conventions. Code must be structured in such a manner that if specification changes or new features are required, code changes should be minimal. Reusable code must be separated in reusable utility classes, functions or namespaces.

2. Thou shalt not optimize prematurely

Code must be fast, but only if it is maintainable and correct. Fast but unmaintainable or  incorrect code is useless.
Premature optimization leads to horrible design decisions and a lot of wasted time. First write the most beautiful code you can, then, if the code is not fast enough, optimize what it needs to be optimized.

3. Thou shalt write explicit code.

Write the code as expressive as possible. It is better to create multiple utility classes and functions than making the code hard to read. If you read the code and the comments loudly, you should hear the specifications.

4. Thou shalt write testable code.

If you can’t test your code how can you prove it works? Ideally the code should be “unit testable” because unit tests are not subjective. If written correctly they won’t prove that your code is bug free, but will prove that the testing scenarios you considered during development where not altered by modifications.
Also when a good testing scenario pops into your mind, write it and test against it. If a bug is reported, if possible, the bug must be transformed into a testing scenario.

5. Thou shalt not be superstitious when writing code.

Do not copy and do not write code you don’t understand. Do not put extra code into your project “just to be sure”. Extra code is not good, it is actually dangerous. In a few weeks you won’t be able to distinguish between the good and the extra code. You won’t be able to remember why you added the extra code. Maybe you have a bug in the extra code. The extra code will take CPU power to be executed. The extra code is crap!
Write code that is useful, that is mandatory to solve your problem and write it for a good reason. You should not write code because you saw on the Internet that usually when you create a window, you also print out its  handler. Do you need to print the window handler? Is part of  the specification? NO? OK, THAN DON’T DO IT!

6. Thou shalt write code that works, according to the specifications, in all scenarios .

If the season or the temperature of the room can influence your application’s behaviour, your code is not correct. Your code should not depend on: compiler version, hardware, weather, karma etc.

7. Thou shalt consider the worst case scenario when optimizing.

It is better to consider the worst case scenario than considering an algorithm to be fast solely on the fact that it runs fast in the best case scenario.
Usually if worst case scenario is not fast enough,  the implementation is not fast enough. When optimizing, be pessimistic. Even if the worst case scenario is not an issue, is better to consider it.

8. Thou shalt not ignore errors and warnings.

You should log all your errors. If you want to ignore an error then comment it with something like:

try {
} catch (Exception e) {
  // We ignore this because we have a good reason to.

About warnings, maybe you live in a society where the word “warning” means: everything is OK, life is beautiful, continue what you are doing. I my dictionary the word “warning” means DANGER! something really bad is going to happen!. In my world one shall not ignore warnings.

9. Thou shalt have no (other) gods.

Just because some guru from the Internet did something in a particular way, it doesn’t mean it is correct. If an experienced programmer did something in some particular way it is NOT beyond question. If you think of a better solution, or you think that a code is wrong, you should question the code. Never consider a code to be proven as good just because it is written by some guru.

10. Thou shalt comment thy code.

Comments should describe why a class or a function is needed and how to use it. They should contain relevant and helpful information, should be as expressive as possible and should complement NOT replicate the code it addresses.

But beware infidel! If you must comment you code o understand it, consider refactoring. The code must be self-explanatory.  The comments should explain the intend not the implementation.

Comments like:

  // TODO: adasdasd

are not comments. You should consider them as compilation errors that must be immediately fixed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s