Some principles for better coding
In my previous post I showed you how a good rule (“always write tests”) can be wrong in certain cases, and for each individual case I gave some alternative suggestions. How did I go about coming up with this exception to the rules? And more importantly, how can you do so?
Underlying the rules you have been taught are principles. A principle is a general guideline, whereas a rule will tell you exactly what to do. Knowing when and how to apply a principle requires more thought than simply following a rule. I plan to discuss this at some point in the future. At the moment however I’ll limit myself to listing some of the principles underlying my last post:
- You are more than just a rational thinker. Pay attention to your body: sometimes coding tasks are hard because you need a snack, or some sleep. Don’t ignore your emotions. Instead use them as a guide for more structured and logical forms of thought.
- You have a limited ability to keep details in your head. Computers do not suffer from this problem, so use them to compensate for your limitations.
- Whatever problem you’re having has already been solved in some form or another by someone else. We can all stand on the shoulders of giants, we just need to take the time to find the right one to stand on.
- The goals of your project are the only way to measure what software quality means. If you’re throwing away your code in an hour you probably have different measure of quality than code that will be used for a decade.
There are many more principles, of course, but even internalizing just these four will make you a better programmer. In my next few posts I will discuss other applications of these principles so you can see them used in other contexts.
Meanwhile, if you re-read my last post can you see how I applied these principles? Are there any other principles you can deduce? Send me an email with any ideas or questions you have on the subject.