One of the obstacles any static analysis tool encounters is the ease with which developers can manage defects that are not pertinent to their development. Oftentimes these “defects” for whatever reason simply do not apply. The most known case of such defects is false positives.
Kiuwan offers many features, today we are going to highlight the “Defects Mute” feature where you can select defects in a specific application analysis and mute them so they are not taken into account by Kiuwan when calculating indicators to assess the maintainability, security, efficiency, portability, and reliability of your application. The selection is then saved for that specific application only, and will be applied in any subsequent analysis to ease your development processes.
For the purpose of explaining how to use this feature, we have analyzed a simple chess game application written in Java where we can see there is a lot of room for improvement in terms of the Kiuwan indicators.
Now, let’s see the found defects in detail. We have 554 defects, but looking closer we find that 29 of those defects come because we are instantiating objects in loop bodies, which is not a recommended thing to do. In this case in particular, given the nature of the application, we believe it is ok to do it. We need to mute these defects for this application.
We open the ‘mute defects’ functionality from the defects menu on the top of the page. A muted defects box pops-up in the page. Now we just drag and drop the defects to mute from the list to the box. We can document the reason why we muted the defect including a comment for fellow developers and we can move on.
We can not only do this at rule level; we may want to mute defects at the file level and even at the line of code level. Let’s see.
The next defect is about not allowing the use of Runtime and System classes. Let’s open it.
In the Match.java file we see the defect comes from using System.getProperty and we decide that it is ok for that file, so we drag and drop the file in the box to mute it.
Now in the Board.java file all the defects come from using the print or println methods except the first one that uses the flush method. We decide it is ok to use it in this case, so we drag and drop the line of code in the box to mute this one too.
Once I’ve muted and documented all the defects that should not affect this application, we click the recalculate and save button on the top of the page and Kiuwan will recalculate the indicators for this analysis on the fly, not taking into account the defects we just muted and saves this configuration for any subsequent analysis.
We realize that muting the use of the System.out.flush() method does not make any sense if we are not muting the other System.out methods. We just click the garbage can for that muted defect to unmute it, and recalculate and save again.
You can see that all muted defects still appear in the defects list, but they are grayed out and have this little icon on the left. If we go back to the application summary, we can see that we have that same icon, telling us that the indicators were calculated taking a number of muted defects into account.
We have learnt how to mute some defects for a specific application when it makes sense and is important for you. It is a great way to, for example to manage false positive results.
Thank you and have fun analyzing!
