Using Sonar is a great tool and it helps to keep the code cleaner and hopefully less buggy. It can even help to change the way you write code as it has done for me. Little things that are violation to rules of compliance are things that I did not previously pay much attention to. For example hiding the constructor of a utility class. Might sound not so bad, but when the day comes that you see a piece of code where someone is instantiating a utility class and using its static methods trough the instance you might think differently. The day might never come if you are lucky, but for those who are lucky enough to avoid those niceties there is a web site to get a quintet with this type of production code: The Daily WTF.
You might be working on a small team where everyone is right there, easily in the communication range. In a small team you might quite quickly come to know the way others work and see their “style”. You might even be able to influence the way they work if you see that something is very wrong. In a team like this you might think that there is really no need for strict coding guidelines or need to document everything. I mean you can ask the person sitting next to you easy as that. Keeping the codebase clean and consistent might feel like a secondary thing, after all you can agree with your colleagues how to do things. After all good coders do not need documentation they can read the code, right? Am I right? Now I am not a business person or that good at math, but I might think that it is much cheaper to read the documentation and comments in 5 minutes than spending 2 hours trying to figure out what the code does and why. Now this is something that brings out the importance of documentation, commenting and consistent codebase. If they are all in check you can probably get the hang of it in 5 minutes. The documentation tells you what and hopefully why is something done for. The commenting gives you more detailed explanation of what is happening inside a method for example or the contract that some API follows. The consistent and clean codebase gives the ability to easier understand some part of the code if the need arises. To conclude this I think it is just as important in a small team than in a big team to maintain the quality of the software by documenting, commenting and keeping the codebase consistent. In a small team you might think that some of these things are not as important because the people are right there and they know what is going on, they know the codebase and they know the product. Nice thought and working one in an imaginary team that stays the same during the entire lifetime of the product. After a long day working in a team like that it is always refreshing and enjoyable to drive home through the rainbow lane and feed your unicorn once you arrive to your cloud castle.
There are tools that help you keep things in check. Tools that most likely would be a very good help even in a small team. Sonar is one of the tools that can help you maintain the quality of your codebase. It shows a lot of aspects about the code and when reacting to it can reduce the complexity and increase the quality of the code. As I already mentioned it might seem to be worthless to clean up all the rules of compliance violations in the code as they might seem quite small issues. Now small issue is a small issue, but when you start growing the number of small issues exponentially then you turn your potato salad in to a bowl of spaghetti. Believe me I know what I’m talking about. Being in the work life for more than ten years you might have seen things and done things, I know that I have done the same mistakes that I now rage about. I am not special in this case and point is not to point my finger at people, but to try to give something they can learn from. I mean after all it seems like that whole life is nothing, but learning if you are willing to learn. I have used Sonar as a tool of learning. I have tried to change the way I write code and what aspects I try to pay attention to. The issues Sonar complains about is not something thought up by a single developer who have made the rules in his liking. No, they are the things that you can read from books and from the internet. They are the out come of a collective thinking and experience gathered during years of developing. If there are something that you don’t like about Sonar complaining about I think it might be a good moment to take a look at yourself and to think is the Sonars check annoying and wrong or should you be the one that changes.
Now there are things that I do not agree with Sonars default rules. For example we use the Allman style in one of our projects and Sonar does not take this into account when calculating the lines of code in a method for example. Then there is the “Unnecessary Local Before Return” rule. Now there is nothing wrong with it as such, but when using generics then there might be a reason to use the local before return. In case you happen to do casting on the return value then there should be local variable before return. This is because when you suppress the warning the scope should be minimum and you cant suppress it in the return statement. Now I wont go into details about why you need casting in a situation like this, but you might end up in a situation like this of course keeping the casting safe if possible. For example in one case we use Java’s API to get parameter types of a method. We can’t change the signature of the API so we get Class<?>, but we return Class<? extends SomeType). We do a type check and if it is ok we return the value and cast it from Class<?> to Class<? extends SomeType>, this cast should be safe because of the type check. We use the local parameter to do the casting to minimize the warning suppressing scope, but Sonar does not understand this. Now these are just two of those rules that I think that I sometimes do not agree with, but sometimes I do. This is one of those situations that I might say that Sonar is piece of shit software and you should not use it. This is the kind of reaction that you might get from someone who is unwilling to change their methods and way of working. I know that in my case these rules can be changed or remove from the check, but I just need the time to learn how to do those things. It is not Sonars fault that I have not had the time, or motivation, to check how to change these things. The annoying things in Sonar are not Sonars fault. It is my fault that I sometimes get annoyed by some of these issues. Maybe I take it too seriously and spend too much time on it. Others are sometimes very occupied with other projects that are based on the old code. Now the old codebase is something that we do not run through Sonar because we do not want to risk blowing up a server rack when the code would be analyzed by Sonar. I mean it is an old codebase.
Now for some conclusion. Sometimes it might be ok to not to care about small issues. But if this becomes a way of working you will probably end up with a big pile of small issues that are harder to fix compared to that if they were fixed right away. And although it might seem like not a big deal to have consistent methods in a small team it really might be a big deal. For example the one point that I already pointed out is very real, the team might not stay the same all the time. I know this because I handed over my letter of resignation (email) today. And the current team will get even smaller during next fall when one of my colleagues fixed-term contract ends.
I would give you this advice: Even on a small project try to do things for others and not for yourself. One of these days you might be the other who reads the code. If you do not follow this advice you might end up in a situation that you find a piece of code that looks messy and does not make any sense. You might wonder that who wrote this piece of shit? And the answer might be right there in the mirror.