Software Development

Is your codebase smelly? Find out with the help of SonarQube and the Smells plugin!

In the project which I recently joined, I discovered a set of annotations, (part of the code) that eventually did not add any functionality but they were ‘marking’ classes or fields  as a potential bad implementation, or as a potential case that may need to be reworked. The original author, had created a very elegant way (imho) on annotating parts of the code, for things that needed to change or to be improved. This mechanism was mostly targeting less senior contributors so they improve and at the same time, it was marking ‘smells’ in the code that unfortunately were not a 5 minute fix and might need a bigger change or discussion around it.

 @TechBebt ("rework this method, so that takes care this business concern")
@Refactor ("Use the proper data structure for this operation, see LinkedList");
public void doSomething(String aParam){

In the past I used to work in projects where this kind of code-review and comment process was performed using our famous following comments. You might have some of those in your project I guess.

// TODO 
// FIX-ME

I really liked the annotation approach, so since I am new, I started searching for them all over the place. When I found something that I could fix, I followed the annotation’s description field, and I could provide a small bug fix. It seemed to be a bit cleaner than the long sentenced TODO items. The problem with the above annotations is you will bump into them, only if you happen to see them, or search for them in your IDE, where TODO or FIX-ME usually show up in IntelliJ’s or Eclipse’s task (todo) list.

At the same time, I proposed to install Sonar for the team and eventually monitor the ‘health’ of our code base improving the exposure of this information to a wider audience. The more you expose your code problems to the team, the easier you make this information to anyone, the more chances you have members to contribute fixes rather than dictating it as a process.

While I was configuring Sonar, I discovered the Qualinsight Smells Plugin, along with their maven library. Eventually it is a library that contains similar annotations to those I discovered in the project, so you can add it as a dependency in your project and start ‘marking the smells’. These annotations then can be scanned by the related Sonar Plugin, so when you code base is scanned, in the final Sonar report, you can have a list of  all the annotated ‘Smells’. You can go through the simple documentation on github. A smell annotation looks like this:

@Smell(minutes=10,reason="This class should be redesigned in order to", 

type=SmellType.BAD_DESIGN)

You have to indicated:

  • an estimate of time for a potential fix.
  • the reason, actually the description of the smell.
  • and a set of predefined types, in order to specify what kind of smell it is. The provided list is  sufficient enough to cover most of the cases.
  • You can find an example of project configuration here.

When the Sonar report is ready, the smells are going to be listed , as the image below illustrates.

smells

I really liked the overall approach. Despite the fact that our u ltimate goal is eventually to fix the code and only ‘annotating’ defects, I still think it is a very elegant idea. Especially when your team consists of less senior developers or ‘devs’ that they don’t pay attention to things like quality and maintainability of the code base, it is a very ‘constructive’ and elegant way to bring forward these concerns and with the help Sonar, increase their exposure. It is also a team effort, identified Smells are not predefined rules from findbugs or PMD, they are human identified  points, there might cases where the code is fine, but it does not implement correctly the business.  Sonar enables non technical stuff to eventually have access to the ‘state’ of the project, so yet another way the product owners/ managers to a better understand about ‘technical debt’.

So…is your code base smelly? If yes do something about it. Nobody likes smelly code.

Paris Apostolopoulos

Paris is a senior software engineer focusing on J2EE development, loves Business process modelling and is keen on software quality challenges. He is passionate about Java and Java communities. He is a co-founder and administrator of the first Java User Group in greece(JHUG.gr) and occasional speaker on meet-ups and seminars and regular blogger. For his contributions and involvement on the Java community he has been awarded the title of Java Champion in 2007 by Sun Microsystems.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button