In this article, I am going to explain how to analyze the SonarQube results and how can we fix issues listed by SonarQube. As we know SonarQube is used to identify the bad code coding practices, code duplication which may lead to performance issues, and issues related to security vulnerabilities. In addition to this, I will also try to show how to control the rules against these parameters and customization the rules.
Users should see the above screen if the project analyzed by SonarQube. Where “Project Analyze” is my ASP.NET solution and SonarQube already analyzed the code and showing the result. If the user still not installed the software or facing difficulty installing the SonarQube software, read my previous articles below.
To check the complete result in detail we supposed to navigate inside our project. To navigate inside our project we just need to click on the “Project Analyze” link, “Project Analyze” is the title of SonarQube project and it was given while analyzing the code.
In the above screen, we can able to see the results in detail. There are two main tabs there by the name New Code and Overall Code. The New Code tab will show results only for new code changes, which means if we make any change in the code and re-run SonarQube again then if there are any observations by SonarQube in new code changes then that particular changes result will be shown in the New Code tab. Overall Code will show consolidated analysis results always.
As per this article writing time SonarQube categorizes its analysis in 6 categories mainly.
- Bugs
- Vulnerabilities
- Hotspots
- Code Smells
- Coverage
- Duplications
Bugs found in SonarQube Analysis
The bugs found in SonarQube analysis is not code bugs instead its code quality bugs. That means if there are any code quality issues, that will be considered as bug in SonarQube Analysis and clearly its not related to regular bugs which can be found in application functionalities. Bugs found in SonarQube may not harming functionality of the application, but it indicates code quality issues.
So lets examine this with an example. First we need to check bugs in detail. To view bugs in detail we supposed click on the Bugs as shown below image
Below image shows the 196 bugs found in SonarQube
Before going into detail about the bug, we can see left-hand side there is a Severity category that contains 5 types of severity Blocker, Critical, Major, Minor, and Info. This Severity tells how server particular bug is. For example, Blocker means more serious issues compare to Critical, Major, Minor, and Info. Next Critical is a more serious issue compare to Major, Minor, Info, and less compare Blocker. Likewise, bugs will be categorized based on their severity.
In the SonarQube analysis result, we could see letters next to a number of issues in each issue type as highlighted below image.
The letters A, B, C, D, E tell how severe a bug it is. The letters will be shown based on severity category, which we discussed above like Blocker, Critical, Major, Minor, and Info. If there are any Blocker bug is present in the result then, it will show the letter E with red color. If any Critical Bug is present then the letter D will be shown with light red color. If any Major Bug is present then the letter C will be shown with orange color. If any Minor Bug is present then the letter B will be shown with light green color and if any Info Bug or there are no more Bug present then the letter A will be shown with dark green color. This also called a rating, my project Bug rating is E.
As discussed above same applies to Vulnerabilities rating, Security Rating, Security Review Rating, and Maintainability Rating.
Now we can discuss in detail about Bugs. Let’s consider one Blocker Bug and try to understand why this was found as a bug and how to solve this Bug.
For example, I have opened one of the Blocker Bug from the list shown in the above image. The bug description says “Dispose ‘webClient’ when it is no longer needed“. This issue will not create any harm to the functionalities of the application instead this may harm application performance. Likewise, issues found in SonarQube will not harm application behavior and functional point of view. Issues found in SonarQube may harm the application performance or security. Next to the Bug description, we can able to see “Why is this an issue?“. If we click on “Why is this an issue?” link, then we can able to see the reason for the issue with appropriate solutions along with examples.
For “Dispose ‘webClient’ when it is no longer needed” issue we can able to see “Why is this an issue”. It shows an appropriate solutions with explanations and examples.
Once the Bug identified we can able to get many options as action for that Bug. Action types are
- Change issue type, for example above bug which we have taken as example is not a bug instead its Vulnerability or Code Smell type then we can change the category as shown below image
2. If we want to change the severity of the issue, then we can click on present severity and change as shown in the below image
3. We can maintain statuses of the issues like Open, Confirm, Resolved etc. as shown below
4. We can able to assign the issue to some other user as shown below image
5. The last action type is Comment. Users can add their comments for the particular issue.
Vulnerabilities found in SonarQube Analysis
There is only one Vulnerability in our present example project. But other features are similar to Bug issue type except, the issue type category is different.
We can able to see only one minor Vulnerability in our example project. Will try to understand what can be the Vulnerability issue type. In this example, we can able to see the issue description “Handle the exception or explain in a comment why it can be ignored.” This issue says there is an empty catch, where we care not handling or capturing the issue. So this is a Vulnerability in the application but it will not harm the application functionality.
Security Hotspots found in SonarQube Analysis
There are 24 Security is there in our current project example. Security hotspots are the code blocks where security is a concern and not handled the block for security point of view. We can analyze this with an example.
In the above image, we can able to see a security hotspot tagged as code injection. The issue is related to JavaScript where the mentioned line is a security concern as viruses can be injuncted. So it is considered a Security Hotspot. Similar to Bug, we can see the option to review the issue, assigning the issue to a particular user, and other options with proper explanation.
In Security Hotspot, SonarQube provides an option to review the Security Hotspots one by one, if the user feels it’s not an issue and the Hotspot is safe then the user can change it to safe. So like this user has to review all the security hotspots. Accordingly, the review completion percentage will be shown on the analysis overview page.
The security rating is E with red color when less than 30% of Security Hotspots are reviewed. Likewise, The security rating A with green color will be shown if 100% review is done.
Code Smells found in SonarQube Analysis
Code smells are related to good coding practices. These are like warnings found in visual studio.
In the above screen, we can able to see the 1894 issue as Code Smell. We shall try to understand how Code Smell looks like with an example.
In the above example, the issue says “Remove this unnecessary ‘using’“. We can clearly observe that there are many unnecessary using statements, which are not used in code. Those are not really an issue but it’s not a good coding practice. These things may or may not be related to the performance of the application. There are other options similar to Bugs, which we already discussed in the above Bugs section.
Debt
Along with Code Smells, we can able to see one more metric by the name Debt or Debt days. Also, this is called Technical Code Deb Days. This is related to overall project maintainability.
In the above image, we can observe that there 27d, that is 27 debt days. On the right side, we can able to see how 27 days divided. There is a Debt Ratio that shows 0.5%. Maintainability rating is A when the technical debt ratio is less than 5.0%. Technical code debt represents, how difficult is to maintain the code. Code maintainability will be difficult when all other parameters are high. The parameters Bug, Vulnerability, Hotspots, Code Smells, Unit Testing, and code duplication are the measurement of maintainability.
Coverage found in SonarQube Analysis
Unit Testing Code Coverage of the application will be calculated and shown in the SonarQube Analysis result if Unit Testing project is there and Test framework(s) must be compatible with Gallio.
In my example project, I have not created any Unit Testing project, so it is showing 0% as coverage in SonarQube Analysis.
Duplication found in SonarQube Analysis
Duplication refers to repeating the code in an application. In my code example there are 577 duplication code blocks shwn in below image.
In the left side, we can able to see Duplicate Files, Duplicate Blocks, Duplicate Lines and Density of duplication. Density shows the Code Duplication percentage, in our application its 17.8%.
Project Information and Rules
There is a option to check the project information with Rules applied on the code analysis.
As shown in above image, we can navigate to Project Information.
We can able to see the total number of code lines at the top above and at the bottom, we can able to see Quality Profiles used. If we click on Quality Profiles, we can able to check the rules used against the code to analyze the code quality. For example, we can navigate to C# Sonary way profile.
In the above screenshot, we can able to see Rules for each category and whether it’s Active or Inactive. These are SonarQube built-in rules and that will be updated by SonarQube software.
To create our own or modify existing Code Rules Profile, we supposed to navigate to Quality Profile menu from top as shown below image
In the above image, we can able to see different profiles like C#, CSS, HTML etc. which is part of the default SonarQube developer profiles which consists of rules to check code quality. On the right and side of the screen at the top, there is an option to create our own quality profile.
In the above image, we can able to see there is an option to copy the existing quality profiles. Using this we can create a copy of the built-in Sonar way quality profile. Then we can activate and de-active some rules, based on our requirements and our convenience.
Administrator
SonarQube analysis report can be viewed without login to the application by default, for administration activities users need to log in and user should be in Administrator group.
If navigate to Administrator page as shown in above image, we can have administration option which includes User Management, Software update, installing addon’s from Marketplace and other configurations.
Conclusion
I have discussed about SonarQube Analysis result of ASP.NET project. In the analysis we could see few third party library files were having issues and that cant be fixed as it may take lot of time to fix those issues. Our main concern should be our written code where we supposed to fix issues related SonarQube analysis result. As we upgrade third party libraries for newer versions in future, those issues may be fixed by respective developers. Also we could understand how we can manage the issues and we could manage rules applied against the code for analysis. At the end we could understand about Administrator related configurations at the high level.