A few weeks ago I published “10 commandments for creating good code”, the article was focused on the physic code characteristics but it didn’t mention anything about best practices to follow to produce such code, to compliment it in this article I would like to present what in my opinion are the five more important practices to take into consideration to create good code.
Keep it simple
I strongly believe that the number one problem with unreadable code is over engineering, we learn so many techniques, frameworks, tools, patterns… that we actually believe that if we can use them, we should use them, and it actually should be the opposite, the best solution is always the simplest solution, remember: “There are no hard problems, only hard solutions”.
As I wrote in a previous post, there are four main traps that may keep you away from keeping things easy:
- If all you have is a hammer, everything looks like a nail.
- Because you can, It doesn’t mean you should.
- The more things that can fail, the more things that will fail.
- The more prepared is your code for change, the more difficult is to change your code.
Visit the article: For god’s sake! Keep it simple! to see a detailed explanation on these 4 traps
Make it work, then make it fast.
“The best is the enemy of the good.” Voltaire
“More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.” W.A. Wulf
“We should forget about small efficiencies, say about 97% of the time: Premature optimization is the root of all evil.” Donald Knuth
They are great to:
- Perform regression testing
- Help you design new code
- Validate your new code
- Boost your productivity
Test early, test often, test automatically! If you are interested in further reading, you might want to check out: How to write a good test case and Top 5 considerations to build software without defects.
My five tips on code reviews are:
- Make your code reviews often. At least once a day.
- Make your code review short and Informal. Something like: “Hi Mike! You mind coming over to my for a quick code review”
- Make your code review with different reviewers.
- Keep a positive attitude.
- Learn to enjoy the code reviews. A code review should be seen as a learning opportunity
For more details check the article 5 tips to make good code reviews.
A special mention deserves pair programming, pair programming is the ultimate way of code reviewing, not only makes code reviews unnecessary, but it also increases the code quality and the productivity.
One of the biggest recent mindset changes is from refactor = bad to refactor = good, saying that refactor is good is saying that you know that you are going to make mistakes, but that you are going to be ready to fix them, that’s quite different from the refatoring is bad mindset, where you put a lot of effort in not making mistakes, which is obviously wasted because, let’s face it, that’s impossible.