Become an awesome programmer by following these 10 rules

If you are a programmer, you often search for guidance on style and best practices. However, the truth is that after a few years of programming in any given language you start to create your own style. This style will most likely resemble the style of others with the same level of experience.
For those of you that do want that little push in the back, here are my rules of programming.

Rule #1: A list (or an iterator) should never be null.

This rule is particularly important for .Net languages, it is my number one rule because it seems like developers always iterate over a list without ever checking if it has a value in the first place. I see it so often that I believe it is a fundamental flaw in the design of the .Net framework.

var products = default(List<Product>);
foreach (var x in products) // <-- this will explode.
    Console.WriteLine(x);

Rule #2: Do not catch an exception that you will not handle.

Nothing is more frustrating than finding a piece of code that will catch all exceptions only to rethrow them. The problem with that approach is that in most cases you lose the actual stack trace, making it hard to debug production problems.

Rule #3: Do not touch code that functions.

There are two main reasons why developers tend to change the source code without it being requested by the customer.
1) Because it helps them in the process of getting to know the code, by rewriting the code, it helps them to understand the logic.
2) Because they think it violates some holy design paradigm. It’s like a plumber coming into your house for a new toilet, but you suddenly notice that your bathtub got replaced because the plumbing gods told him magenta bathtubs are the new standard.
The truth is your customer does not care, if the code lives in a live environment then do not touch it.

Rule #4: Refactor your code before you implement a new feature, not afterward.

Remember rule #3.

Rule #5: Readable code is not the same as short source code.

Programmers need to read code ten times more often than writing code. Please make sure your code is easy to understand. If you need to brag about how only you will ever understand the code you just wrote, then you probably did a bad job.

Rule #6: Restarting from scratch isn’t an option, if your code is spaghetti, live with it.

How many times have I heard that the code would be so much better if you could just start from scratch? First of all, it is admitting that you failed or fail at handling a challenge. So second, well yes it probably would result in better code… if all conditions would be the same as when you were working on the first version. The same as in the same team, the same customer, same scope, same timing, but that is never the case, is it?
The fact is that restarting from scratch is not a guarantee that this time it would be better. The scope, the team, and the timing would probably be different, so in reality, it would be a different project. The solution to this problem is to make sure you respect Rule #4, after a while, you will get out of that mess, don’t give up.

Rule #7: Only implement what is necessary, don’t write code that isn’t essential for the feature at hand.

Programmers and architects are very dysfunctional in that way. When a customer describes his new feature request, developers tend to say, “Nooo, customer… that is not what you need, what you need is something that’s ten times more complex.”.

Rule #8: Only use or apply what you know.

Don’t use techniques or technologies that you do not master. I am sure you want your dentist to apply this rule.

Rule #9: If you have multiple solutions to a problem, choose the one that’s backward compatible. If you have multiple solutions to a problem, chose the one that requires the least amount of permutations.

In other words, keep it simple and be lazy.

Rule #10: Know when to ignore the rules.

This one is probably the most important one. Don’t blindly follow anything that comes from the interweb. The guidelines, design standards and whatnot are in most cases written in a particular context. If you have difficulties applying something, then you probably don’t need to use it, or you are violating rule #8.
I’m interested to hear about your rules in programming, let me know them below in the comment.