How to write better code – 6 things I did not found on the first page of google search results

I know there are millions of answers to this question (I for one get 484,000,000 hits on google when I search for How to write better code). They all seem to revolve around the same general idea, so I will not be repeating that. You are free to do a google search yourself and read through those.

I will however, be sharing some tips that I picked up that you may find useful. Here we go:

1. Do not compromise

We all know when we are doing a hack, or a nasty work-around because the right way takes too long. We know it, and we still do it. Maybe it’s late in the day, and we just want to go home, maybe the deadline is closing fast and someone is going to be really mad if the project is not done on time or maybe we just can’t be bothered to do things the right way. My advice to you here is, you guessed it, do not compromise code quality. Compromises made now will slow down development in the future, which will in turn lead to more compromises and so on and you will end with a mess of a project that you will need to maintain. And that’s no fun 🙁

2. Less is more

A programmer’s proficiency is not measured in the number of lines of code they write, it’s more like the opposite. The more code you write, the more chances to break said code. The odds are against you. If you have to think twice as long on task to write half the code, do it, it totally worth it.

3. DRY

Don’t repeat yourself! I’ll say it again: Don’t repeat yourself! (pun intended). In my experience, the worst codebases I had to deal with are the ones which chose to implement the same logic in many (and often quite creative) different ways. Don’t do that to the person maintaining your code. If you have to use the same logic in two different places, be sure to have the code in one place.

4. Follow the existing pattern

This is an extension of the previous topic. Please try to avoid adding a new pattern to the project, unless it’s really necessary. One style of doing things should be enough for one project. I accept that this may be hard. Especially if you are just starting on a new project that seems to be doing things differently from what you are used to, but don’t give into the temptation. Keep the project simple and follow the existing pattern, even if it means more work for you now. And remember: It will get easier with time.

A notable exception to this rule is the process of replacing the existing pattern with new and improved one. If you are doing that you can have two patterns in the project at the same time, while the old one is slowly retired.

5. Automated tests

I really don’t see nearly as much as these that I would like to. If, at any point in the development process, the thought that you need more tests crosses your mind, you are probably right. As you might have guessed if you follow my blog, I’m a big fan of automated tests (maybe enough to write an article about them some day). Automated tests are great, and they have many advantages to them. They give you the confidence that what you just changed did not break any hidden functionality. They serve as an always up to date documentation for the project (as long as they are passing).

6. Common sense must prevail

We need to take a step back now and acknowledge that each and every one of the points above can be taken to extremes. As you might expect, taking internet advice to extremes is not advisable. So I leave you with this: Whatever you do, don’t forget to use your basic, human, common sense. You are free to bend and adapt the rules so that they make sense given the situation.