Code quality not required
Why the notion of code quality is subjective?
Nowadays, every developers talk about code quality. This concept is based on the fact that the quality of your code is something measurable..
The question is:
Why do you try to apply general rules to measure the quality of your code when measuring the quality of this code is something very subjective?
So, the goal of this post is to help you to apprehend the notion of code quality depending on your experience and the context of each of your projects.
Code Quality
The expected code quality depends on the context of your program. So, let’s assume that we’re in the context of a web project. We manipulate the codebase everyday. Here I’m going to share with you the factors that seem pretty important for me.
Readability
When you implement a feature, what are the factors that can help you to decide if the quality of a given piece of code is acceptable (or not) ? You’d reply me that your linter or your code analyzer takes the decision for you.
Well.. that’s not bad..
With a bit of configuration, these tools can help you avoiding to pollute your code (unused variables, code alignment, etc..) and they limit the branching of your program (ABC, cyclomatic complexity, etc..). I guess we can agree on the fact that a code with limited branching and with a cleaner code enhances the code readability.
So, the readability of your codebase is a factor that can help you to determine the quality of a code.
Documentation
By documenting your codebase, you enhance the general comprehension of the code and it can also give a bit of context about what was the mindset that led you to take this decision. Documentation can be implemented in many ways:
- comments
- generated documentation (from the codebase, Swagger, etc..)
- documentation in the repository
- wiki (Confluence, Github Wiki, etc..)
- naming (variables, methods, classes, etc..)
SOLID
SOLID principles are a set of practices that aims to help you to keep your code maintainable in a long term perspective. For me, those are tools.. and I’m not dogmatic on whether using these tools or not. Anyway, I wrote an article on that subject.
So feel free to read it here if you’re not familiar with the SOLID principles.
Test coverage
Having your code tested guarantees that your code has the expected behavior and prevent regression when you modify the codebase. Also, it can be a pretty handy way to understand the context of a feature.
Recap
I consider acceptable a code that is readable, properly documented and that respect as much as possible the SOLID principles (if relevant). Again, the described factors are part of my journey as developer. They’re based on my experience.. and it’s very subjective! Also, if it speaks to your soul, then feel free to cherry-pick and apply the parts you want.
The Clean Code book is also a reference in term of code quality policy.
Now, let’s see how to analyze the context of your application to see if applying a strict code quality policy is relevant or not.
Analyzing the context of your program
Another subtlety that you need to be aware of is:
When is the right moment to apply this policy?
And.. there is no right answer to this question.. Otherwise, there is a set of decision support tools we can use to help us decide whether is good or bad to apply a strict code quality policy. Let me expose you 2 use cases.
My codebase must be maintainable and evolutive
Let’s take the example of an API maintained by a team of N developers. If you want to update an existing feature, it’s comfortable to have a readable code with a proper documentation. Also, the code that you have to modify is DRY and the class you interact with is isolated and low coupled with the rest of the architecture. Finally, the code seems to be well covered. In this context, you feel very comfortable to modify this code.
Well, when you wrote this code for the first time, you knew that there was a strong possibility that this code would evolve in future. So investing your time in producing a code that corresponds to you code quality policy was a good move.
One shot task
Now, let’s say that your database schema evolves and you need to update your existing records accordingly. You only need to update these records once. So at this moment, investing too much time in applying your code quality policy can be a waste of time. Otherwise, code readability (naming, etc..) and comments are still important here. But, for example, limiting the number of lines of your task is not mandatory.
So, some rules of your Code Analyzer are irrelevant here.
Conclusion
A code quality policy is composed of a set of tools. You must agree that all of these tools are beneficial for your happiness. If no, then remove them from your policy. Having a clear policy enhances the homogeneity of your codebase. Also, feel free to cherry-pick the right tools depending on the situation.
Investing your time in applying a code quality policy must be a choice that is carefully made.
Thank you for taking the time to read this article!
Voilà!
RubyCademy is now available on Youtube! ▶️ 🚀 🤩 💎
We publish short videos (maximum 5 minutes) that talk about technical notions, quick wins and tools (..and a couple of geek stuffs 😅).
Feel free to click on the image below to access our Youtube channel
