Many developers make the mistake of believing that writing robust and resilient code means writing a lot of code. This assumption is misguided, as less code can be more effective. Writing less code is beneficial for several reasons.
Firstly, less code is easier to understand. When there is less code to read, it’s easier to comprehend the purpose and functionality of the code. This makes it easier for other developers to work with the code, as well as for the original developer to revisit their own code later on.
Secondly, less code means less time spent reading it. This is particularly important for larger projects that have many files and functions to keep track of. When there is less code to read, it’s easier to navigate through the codebase and find the relevant sections. This can save a significant amount of time and effort for developers.
Thirdly, less code means fewer variations of what can happen, and therefore, it is less prone to error. When there is less code, there are fewer paths for the code to follow. This makes it easier to test and debug the code, as there are fewer possible outcomes to consider.
Fourthly, less code is easier to refactor. This is because there are fewer dependencies and less complexity to consider. It’s easier to change a small amount of code than it is to change a large amount, and it’s easier to ensure that the changes don’t have unintended consequences.
Finally, less code is easier to debug. When there is less code, it’s easier to pinpoint the source of an error. This is because there are fewer possible locations for the error to be hiding.
When writing code, it’s important to keep these benefits in mind. However, writing less code is easier said than done. It requires a deliberate effort to minimize the code while still maintaining its functionality and readability.
My usual process for writing code involves writing the first prototype that just works. This code is designed to fulfill the requirements of the project or to help understand a new library or endpoint. However, this code is often not particularly readable or maintainable.
The next step is to write tests and refactor the code so it is testable. This is a critical step in the process, but it can be boring and time-consuming. The goal is to ensure that the code is reliable and maintainable, and that it follows the team’s guidelines for code style and structure.
At this point, many developers stop working on the code and create a pull request. However, to truly write effective, maintainable code, it’s important to ask yourself a series of questions:
- What can I delete or refactor while still keeping the code functional?
- Can I write this part using fewer lines while maintaining readability?
- How can I improve the code’s readability?
- Are all the layers of code really necessary, or are they remnants from the past?
- Would my colleagues understand this code, or is it too complex?
By asking these questions and taking the time to refactor and minimize the code, the future reward for yourself and your colleagues is well worth it. Refactoring and minimizing code can be time-consuming and challenging, but it leads to more effective and maintainable code in the long run.