Core Code Quality Principles
Most developers agree that Code Quality is important but often disagree about how to actually improve it. For me there are 4 principles which fit together perfectly to create good code. Before diving into that, let's just recognise how widespread this problem is.
The problem of bad code
Bad code is everywhere. In some cases, it has never had the correct attention paid to making it good code. In other cases, it has been over-engineered to do far more than was ever needed in an attempt to make it good. The biggest problem is that 'code rots'. It becomes harder to work with code the older it is. Using version control, you can see the changes made to each file, who made them, what comment they gave with the change - but even files that haven't changed still rot. As they remain unchanged, they can fall out of sync with the way the application is now expected to behave. This is a common problem and has been recognised in geeky comics such as WTFs/m and XKCD's Good Code.
Trying to solve the problem
This is not an easy problem to solve as everyone's got their own personal tastes on this (see Good code is like good coffee). Sometimes, I've looked back at code that was supposed to be good and see that it's not aged well. Sometimes, the things we do while intending to make things better actually make them worse. So how can we help ourselves to write good code?
Steward Digital's 4 core code quality principles
We think there are 4 principles which any developer can bring together to help them on their quest for good code:
- TDD - Test Driven Development
- DRY - Don't Repeat Yourself
- YAGNI - You Aint Gonna Need It
- SRP - Single Responsibility Principle
So how does this help us? Using TDD shows us that the code that we write actually works and serves a purpose. It makes sure that any future enhancements don't break existing features. DRY and SRP have a beautiful way of fitting together. Together they inform us that each unit should only do one thing without repeating anything. SRP has the principle of the 'single authoritative source' of information or algorithmic logic. This goes beyond just making sure you're not creating repetition and into good Separation Of Concern.
YAGNI is the newest addition to this list. YAGNI is all about not solving problems that don't exist yet - you solve "today's problems today and tomorrow's problems tomorrow". If you're building a system that needs 5 features today and 10 next month, you should build it with 5 features now (not 7.5!). YAGNI helps to avoid extra code which would also need maintaining. The more code the faster the rot.
Apply them in order
The order is important. If you applied YAGNI first you'd question whether you need good unit tests and whether it's really worth removing repetition. Our experience is that these things are essential for maintainable code and YAGNI helps us to avoid focusing on any unnecessary features. Single Responsibility Principle is bottom of the list because it only comes into play when there's already no repetition, it's below YAGNI because there's a danger that we spend time focussing on 'the perfect' place for it rather than one that meets our current requirements.
Building on the foundation
We follow these principles really strictly because we know they give a good foundation to build good code upon. There are many other principles we use daily, but watching these 4 fit together is the first step we take towards making sure our code is of appropriate quality.
Why not try them for yourself?