Effects of code quality checks
Code quality is a weak spot in nearly every software project. This is especially true for legacy projects. What once was elegant, over time became rougher and finally incomprehensible.
Monitoring and fixing code quality issues is something that has been proven to increase the quality of the application and decrease the delivery time to stakeholders. Unfortunately, a large portion of developers do not monitor for code quality or ignore fixing any quality issues.
The first step in adding code quality checks to your code is to know the available tools. The second step is to know how to use these tools and when.
Big effort, little payback
There are a lot of developers and managers who think that writing unit tests is just extra work. Suggesting that we should write more unit tests seems to receive ill responses. I think there are many people out there who still don’t understand the purpose of unit testing.
This kind of thinking is probably the result of following kind of experiences:
- Writing unit tests is really hard and time consuming.
- Even small changes in requirements keep breaking the unit tests.
- Unit tests are not finding any real bugs.
It is not that writing unit tests is somehow fundamentally laborious. These kind of experiences are symptoms of something else.
There is no time for writing tests
Let’s assume we have decided to increase the stability of our software. So we decide to write tests for our code. The problem is that the customer is requesting new features and deadlines are approaching. Testing will slow us down. We can skip them now and write them later, right?
Wrong. Testing will not slow us down. Also if we decide to skip writing them it’s almost 100% certain that they won’t be written at all.
While tests might slow us down at the begin of the development cycle, the truth is the longer the software needs to be maintained tests will dramatically speed us up.
Dead code is a code smell. Dead code is code that has remained around but is never reached or called. It is very common to have dead code in older projects that have not been cleaned up. While being a very common code smell it is also very easy to fix.
Version control systems provide a way to track changes between source code versions. Git is most likely the most commonly used one nowadays. Git can be used in different ways and there is no one correct way to do it. However, there are some pitfalls that might make tracking of changes harder than it should be.
A large class is a code smell very similar to a long method. Some might argue that a lot of small classes make the code harder to follow. However, the exact opposite happens with proper splitting of responsibilities between the classes and naming them accordingly.
How do you handle null?
The most common reason for writing null checks is that you run into a null pointer exception. The second most common reason is that you happened to think about it at some certain case.
The problem is that you are not probably handling null in every single method call. This means that there are potential bugs lurking everywhere.
Null pointer exceptions are bad. Would it not be better if you did not have to check for nulls at all?
We all have been taught that reusable code is good. We all know why we should do it but there are some misconceptions about how to do it.
There are two common misconceptions about reusable code:
- Using inheritance in order to achieve code reuse.
- Creating a static utility or helper class in order to reuse methods.
Mostly these misconceptions are the result of procedural thinking. People usually understand how certain object-oriented principles work. However, it is seldom taught what is the purpose of such principles.
The case of the notorious legacy code
Every software developer has faced the situation. You have been assigned a task to add or change a feature. You know nothing about the particular feature but it does not sound too complex.
This is what you think until you look at the code. You quickly realize that the code is a mess. A monolithic monster with a lot of copy-paste code, no comments, implementation full of anti-patterns and there are no tests at all.
You look at the commit log and curse the person who wrote this big pile of mud. You feel frustrated because it is very hard to get a grasp of what is going on in the code and making changes seems impossible as you are afraid to break something.
Code comments are a code smell. This statement might feel contrary to reason when you have been taught to always comment your code. Having comments might however tell you that the implementation is too complex.
Don’t get me wrong, I am not saying that you should not write any comments. You should however pay attention to when and why you are writing them.