Is writing code the same as writing text? Like normal writing, you have to consider audience and purpose – what is this code for, and who will be reading it? Unlike regular writing, though, you’re generally writing as part of a team, and it’s important that everyone on your team is writing in the same style. Also unlike regular writing, a misplaced word could cause more than just a temporary misunderstanding – it could cause your program to crash, or worse, do the wrong thing!
We practice comprehensive code reviews because in our experience, we find that this reduces total cost of ownership significantly. This is because by having good code review practices, you can keep your code clean and maintainable, as well as significantly improving team productivity. We’ve seen how difficult it can be to maintain legacy codebases when you don’t have clean code throughout, and we’ve found that this up-front investment is tiny in comparison to the gains you make over the lifetime of any software project.
With these differences in mind, it is much more important to have others review your code than it is your writing. At Ghyston,, our code reviews are generally trying to accomplish four things:
1. Keeping code clean
One common saying among programmers is ‘code is read far more than it is written’. When you’re working on a codebase that is larger than a few hundred lines of code, it’s likely that you’ll spend more time reading than you will writing it. Because of this, if you can rewrite your code so it takes a few minutes less for the next person reading it to understand it, you can gain significant time savings across the lifetime of your project. One way of accomplishing this is by having another person read your code, understand what it does, and then ask the question, ‘is there a simpler way of expressing this?’
2. Sharing knowledge across the team
An important metric for any team’s success is their ‘bus factor’ – that is, how many people would have to be hit by a bus in order for knowledge to be lost! Having knowledge spread out across the team has many benefits – it means that if one person is away, another can work on their code. Additionally, it means that when you’re writing code that affects other parts of the system, you have the context to know what’s possible, as well as who to talk to when you need help. When at least one and ideally two other people review all code, there’s no chance that your code will become an unknown land into which no-one but you can venture.
3. Continual learning and improvement
As we all know, standing still in IT means you’re falling behind, and it’s no different for developers. Languages evolve quickly and best practices can become outdated. An important part of code reviewing is making sure that we’re always doing things the best way. Whether it’s a library that you didn’t know existed, or a language shortcut that makes your code simpler and easier to understand, there’s always something new to learn from other developers – and this goes both ways, from reviewer to reviewee, and vice versa.
4. Checking for errors
When working on a particularly complex task, it’s easy to get bogged down in the details and miss small errors. This could be something as simple as returning the wrong value from a function, or missing a negative sign. By having another person read over your code with fresh eyes, many of these errors can be spotted. This isn’t usually sufficient to catch all errors though – for that, we also use Unit Testing, Integration Tests, Continuous Integration and User Testing.
