24/08/2021
3 Things You Can Do Before You Even Start Coding to Improve the Quality of Your Code
Here’s how you can improve the quality of code that you didn’t even
As weird as it might sound to you right now, it’s possible to improve the quality of code that you didn’t even write. There’s an old saying that says a job well conceived is a job half done. This definitely applies to writing code. Being prepared and having a plan can do a lot of good to your code. Making sure you exactly know what you’re going to build and how you’re going to build it can help you increase the quality of your code.
Here are three things you can do to improve the quality of your code before you even start coding.
1. Requirements
A bad habit that a lot of programmers tend to have is that they start coding too fast. The desire to code often results in missing a part of the requirements. And when you don’t know all the requirements things get tricky.
How do you know what to build when you don’t have all the requirements? How can testers know what to test? When is this feature ready? And last but not least, what can the customer expect?
Rushing into the code might seem exciting at first. However, that excitement might end up costing you a lot of time. When jumping straight into the coding part, you’ll eventually lose sight of the bigger picture. There’s a very big chance that you have to refactor a part of the code that you’ve written. In the worst-case scenario, you have to rewrite all of the code.
On top of that, bugs can easily sneak into the codebase when the requirements are vague, missing, or misunderstood.
When all of the requirements are clear the developer knows what to build, the tester knows what to test and the customer knows what to expect. This results in straightforward code that can be properly tested which both increases the quality of the code.
2. Design
Thoughts are cheaper than debugging — it’s easier to throw away an idea than having to refactor an entire codebase.
Designing or having a plan when it comes to building a certain feature is essential. Of course, you can only design once you’ve got all of the requirements.
Jumping straight into coding without having a design is like building a house without a blueprint. You first need to know how big the rooms will be, where you place all the doors etc. If you start building your house without a blueprint it’s inevitable that you’ll run into some issues. This will only lead to rework and is a waste of time.
The time you spent designing is time well spent. Take as much time as you need to understand the project, the risks, and the unknowns. Coming up with the right design usually takes way less time than having to fix the code later on.
Having to make changes during the design phase is rather cheap compared to having to make a change during the building or maintenance phase. Making drastic changes to a sketch is way less time consuming than having to change your code. Not only do you have to change your code, but you should also adjust all the tests for this piece of code.
A good rule of thumb is that the more that changes are made early on in the process than later, the better it is in terms of time and money spent.
When designing you should take best practices into account. The challenge is to make the code as robust and as easy to maintain as possible. Taking the time to come up with the right design results in an end product that will be more thought out and of much higher quality.
3. Conventions
In order to get code that’s easy to read and understandable for any other developer who hasn’t written the code themselves it’s important to have a list of coding conventions.
Every developer has its own idea about coding conventions. Therefore you’ve got to make sure that everybody in the team is on the same page when it comes to the coding conventions. It’s good to know that there are some best practices that you could use as a guideline for your list of coding conventions.
The number of rules that you can add to this list is unlimited and the number of rules can vary. Just do what works for you and your team. Feel free to add new rules to the list of conventions if the team feels like it. The same goes for removing a convention from the list.
In order to check if code is in line with the coding conventions you’ve basically got two options.
The first option that you have is to install a linter in your IDE. This way you could automatically check if the code is written in a proper way. You could share the configuration file of your linter within your team or put it inside the repository.
The other option is that you build a pipeline that checks if your code matches the coding conventions. The pipeline runs the linter every time a developer commits to the repository. The pipeline helps to improve code quality because it gives rapid feedback to the developers. If a test fails the build will fail and the developer will be notifie
