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. Often, these “defects” simply do not apply. The most well-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.
To explain how to use this feature, we have analyzed a simple Java chess game application. We can see that there is a lot of room for improvement in terms of the Kiuwan indicators.
Now, let’s examine the found defects in detail. We have 554 defects, but looking closer, we find that 29 of those defects are caused by instantiating objects in loop bodies, which is not recommended. In this case, however, given the nature of the application, we believe it is okay to do so. We need to mute these defects for this application.
We open the ‘mute defects’ functionality from the defects menu at the top of the page. A muted defects box pops up on 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 the 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 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, which uses the flush method. We decide it is okay 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 at the top of the page. Kiuwan will recalculate the indicators for this analysis on the fly, not taking into account the defects we just muted, and save this configuration for any subsequent analysis.
We realize that muting the use of the System.out.flush() method does not make sense if we are not muting the other System.out methods. We just click the garbage can for that muted defect to unmute it, 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. Let’s go back to the application summary. We can see that we have the 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!
