The SonarQube scanner is a simple way to start gathering data on your project. However, the scanner doesn’t know much about project structures and conventions for programming languages. Those things are all included in the build integration, which will be the topic of a later post.
This post is part of the SonarQube series. You can find the other parts here:
- Part 1: SonarQube: Installation Walkthrough for Windows and SQL Server Express
- Part 2: Collecting Data on your Projects with SonarQube Scanner
- Part 3: Start Analysing Code with SonarQube
- Part 4: Fine-tune the Collection of your SonarQube Projects
- Part 5: How LOC is computed in SonarQube, NDepend and Visual Studio
- Part 6: Customise the Rules in SonarQube
- Part 7: Get SonarQube Ready for Production
- Part 8: Integrate SonarQube with Visual Studio Team Services
- Part 9: Integrate SonarQube with Visual Studio using SonarLint
- Part 10: Leverage SonarQube to Fix Technical Debt in Multiple Projects
Excluding Directories
.Net projects have a bin folder, where Visual Studio stores the compiled application. The scanner doesn’t know that and will include your bin folders, leading to a lot more lines of code for your application and most likely increases the amount of duplicated code. The same happens with the packages folder. That’s the place where NuGet stores all the packages your project needs. Analysing them can be interesting, but it is rather bad for the metrics of your project.
If you only care about your project, then you can add those folders as a comma separated list in your sonar-project.properties file:
|
1 2 |
# Exclude paths not in our control sonar.exclusions=packages/**,**/bin/** |
The ** stars mean zero or more directories and will remove all folders in the packages directory. The same will be done with all bin folders anywhere inside your project directory.
The following wildcards can be used:
| Wildcard | Matches |
|---|---|
| * | zero or more characters |
| ** | zero or more directories |
| ? | a single character |
More information on this syntax can be found in the documentation.
How do you complete the exclusion list?
There may be a more elaborate solution, but I found the trial-and-error approach fast enough:
- Open the web interface of SonarQube and look at the lines of code metric. If you click on it, you will get a list of all your files sorted by their size.
- Look for files that should not be included and add the folder in which they are placed to the exclusion list.
- Save the properties file and run the scanner.
- Refresh the lines of code list when the scanner has finished (be aware that SonarQube needs a few seconds or more to update the user interface).
- Check again if there are other files you don’t want to analyse. If this is the case, repeat steps 3-5 until you are happy.
You now should have a list with only the files you want. If you miss some important files you can modify the exclusion paths to a more precise one.
A nice side effect of only analysing files you care about is that the metrics improve. Your duplication, bugs and vulnerabilities can be reduced significantly. Without much additional work you may turn your project from a D into a B. And even better, you now only have to deal with real problems.
Next
Cleaning up what is analysed will reveal an interesting difference in the lines of code metric. Whatever you do to remove unwanted files, this metric reported by SonarQube will be significantly higher than what Visual Studio finds. The next post will explain how this metric is calculated and why there is such a big gap.