At Qxf2, we have used various static code analysis tools such as Codacy, SonarQube, and others to ensure code quality across projects. This post is about SonarQube, a powerful tool that allows teams to maintain clean code by identifying potential issues and enforcing coding standards.
Typically, when we introduce a static code analysis tool at our clients, we end up dealing with a similar set of questions from engineers. Over time, we have identified the five most common scenarios that teams encounter when introducing a static analysis tool. We are sharing the same in this post.
Static analysis tools
If you are a tester and not familiar with static analysis, now is a good time to read up about this technique. Most of us are familiar with linters to enforce rules around the style of writing code. Similarly, there can be rules that can be run against files (without executing code) to check for security practices, code duplication, common bad practices while writing code, patterns in error handling, etc.
SonarQube provides flexibility in customizing rules, whether globally, for particular directories or files, or even for specific lines of code. This post focuses on how to configure SonarQube effectively by exploring common scenarios and providing actionable steps to tailor its analysis to your project. By configuring the rules effectively, you can prioritize and address these issues systematically.
Scenario 1: First time introducing a static analysis tool
We have first hand experience of introducing an static analysis tool poorly. The team found it confusing and we eventually had to stop using the tool. From that experience, we suggest being more intentional when introducing the tool to a team. In any project, it is essential to configure static code analysis rules effectively to meet the specific needs of the team. When running SonarQube for the first time, it may report a large number of issues, which can feel overwhelming. So talk your team through the problems. Set a policy that no new static code violations should happen in new commits. And setup a plan to tackle the most important existing violations.
Scenario 2: Enable/disable specific rules for the complete project
You can enable or disable specific rules for a particular language using your SonarQube server or cloud setup. Navigate to your SonarQube server/cloud and go to “Quality Profiles”. Here, you’ll see the profiles SonarQube uses while scanning your code.
For example, to enable or disable rules for Python, create a new profile by selecting the “Extend an existing quality profile” option. Choose the specific language, the default profile, and a name for your custom profile. Once the new profile is created successfully, it will appear in the Quality Profile list under the respective language. Right-click on the new profile and mark it as the default profile.
To edit rules, click on the new profile. You will see Active and Inactive rules. Based on your requirements, navigate to the desired section and toggle the rules using the Enable/Disable option. Refer to the attached screenshot for more details.
Scenario 3: Exclude issues on a specific line of code
To exclude an issue on a specific line of code, use the //NOSONAR comment. You can optionally add a description for clarity.
Note: SonarQube has not yet implemented a way to suppress specific issues on a specific line for Python. However, for Java, you can use @SuppressWarnings(issue_id) to suppress a specific warning for a line or method.
The SonarQube team has an ticket for this feature for other languages. Until then, use //NOSONAR, which disables all issues on the specific line of code.
Scenario 4: Exclude specific rules for specific files
To exclude a specific rule for particular files, create a sonar-scanner.properties file in the root directory of your project. Add the following lines:
# Exclude specific rule for specific file sonar.issue.ignore.multicriteria=e1 sonar.issue.ignore.multicriteria.e1.ruleKey=python:S3776 sonar.issue.ignore.multicriteria.e1.resourceKey=**/conftest.py |
The above configuration excludes the issue “python:S3776” (cognitive complexity) for the “conftest.py” file. Similarly, you can define other rules and files to exclude.
Note: If you are using SonarQube Cloud automatic analysis method for your repositories, you need to use .sonarcloud.properties file instead of sonar-scanner.properties file, and wildcard patterns are not allowed. You can also configure settings from the SonarQube Cloud UI. Navigate to your project’s Administration > General Settings > Analysis Scope and update the configuration as needed. Wildcard patterns are allowed in the UI.
Scenario 5: Exclude specific paths or files
To exclude specific paths or files, add the following line to your sonar-scanner.properties file:
# Exclude files sonar.exclusions=**/tests/** |
This configuration excludes all files within the “tests” directory. You can modify the path pattern as needed for other directories or files.
By configuring SonarQube effectively, you can tailor its analysis to meet your project’s requirements while avoiding false positives or unnecessary overhead. Whether it’s enabling/disabling rules globally, excluding specific issues, or tailoring analysis for certain paths, SonarQube offers powerful options for customization. Start configuring SonarQube today to streamline your static code analysis process and improve your project’s code quality!
Work with Qxf2: Technical testers who go beyond the ordinary
Qxf2 isn’t your typical testing partner—we tackle areas like static code analysis and configuration, including tools like SonarQube, that most testers shy away from. If you need QA experts with technical depth and a willingness to dive into developer workflows, explore our advanced QA services for startups.
I love technology and learning new things. I explore both hardware and software. I am passionate about robotics and embedded systems which motivate me to develop my software and hardware skills. I have good knowledge of Python, Selenium, Arduino, C and hardware design. I have developed several robots and participated in robotics competitions. I am constantly exploring new test ideas and test tools for software and hardware. At Qxf2, I am working on developing hardware tools for automated tests ala Tapster. Incidentally, I created Qxf2’s first robot. Besides testing, I like playing cricket, badminton and developing embedded gadget for fun.
