TL;DR overview
- Effective code review with Sonar combines automated static analysis and pull request decoration to surface issues where developers are already working, reducing manual review burden.
- Sonar's Quality Gate enforces code quality standards on every pull request, blocking merges when new code introduces bugs, vulnerabilities, or code smells.
- By focusing on new and changed code—teams avoid being overwhelmed by legacy issues and maintain a consistent quality baseline going forward.
- Automated feedback in the PR workflow enables developers to fix issues before code is merged, shortening remediation cycles and improving team code health over time.
At Sonar, we like eating our own dog food as much as possible. This is not always the case in software development, but in our case since we develop software for software companies, we can do it. We therefore have an instance of Sonar that analyses all our products daily. We've been using it for quite a long time to monitor code quality using features like alerts and SQALE indicators (Technical debt). We have defined a quality gate for the ecosystem that is fairly simple: the SQALE index must be A, the technical debt must not increase between releases and there must not be blocker or critical violations.
This quality gate is good to have but not efficient enough because defects introduced during a sprint have to be fixed all at the end. Instead, they should be fixed as they appear for better efficiency, similarly to code fix when a unit test breaks in continuous integration: this is what we call continuous inspection. We have done a lot of work this year to be able to provide better support for Continuous Inspection in Sonar and have added several services : differential views, SCM information and manual reviews integrated with email notification and with Sonar Eclipse. Manual reviews is really the new hot feature to complements existing services and making code reviews more effective.
How does this all fit together ? Well, this is the subject of this post… Get your Sonar 2.11 started, open Eclipse along with Sonar Eclipse 2.1, and follow the guide!
Develop, test, commit... and sleep well!
Managing code quality is like handling non-regression: while developing, one should not worry about this - a process should do it and notify you in case of an issue. You know already that you can refactor your code serenely because a continuous integration server will check that you did not introduce a regression, don't you? Same applies when you improve a feature, the integration tests will make sure that you did not break anything, right? Similarly, you can feel comfortable when you think about quality of your code, Sonar will take care of it for you.
If you wish, you can also use Sonar Eclipse during your development to run local analyses and get realtime feedback. This is not yet optimum since you can only run full analysis and we are working hard on supporting incremental analysis.
Morning: code review time
After a good sleep and a cup of coffee, the first thing you want to know is how well you coded the previous day : log into Sonar and activate the "since previous analysis" differential views on your project: in a second, you see if new defects have been introduced. Those may identify - for instance - potential bugs, too complex classes or insufficiently tested methods. But whatever those violations are, you know that they increase the technical debt of your application. Fixing a violation is like fixing a bug: the sooner, the cheaper - as the context of the violation is fresh in your mind.
To track the newly introduced violations, use the differential violations drilldown. For every newly introduced violation - there shouldn't be too many as you become more and more familiar with quality rules, create a review and assign it (or - when appropriate, flag it as false positive). If your source configuration management tool is supported by Sonar, finding the developer who introduced the violation is even simpler as his identifier appears next to the violation (as long as you installed Sonar SCM Activity plugin).
Though this process should only take a couple of minutes and will maximize the efficiency for reducing the technical debt, the ultimate objective is to provide a mechanism to notify the person who introduces a new violation.
Before developing again, clean your code
Once you've created all the reviews for the newly introduced violations, you can get back to your favorite IDE. But before starting coding, maybe you'd like to fix defects that you introduced the day before, wouldn't you?
If you're using Eclipse, you are lucky: Sonar Eclipse provides a very efficient way to work with reviews. Thanks to its Mylyn connector, Sonar Eclipse brings all the reviews assigned to you right inside your task view in Eclipse. There too, in a second, you see all the reviews that you have to work on. Open a review, click on a link to open the corresponding file, fix the defect and resolve the review to "fixed" so that it doesn't show up in your task list any longer: this is that simple to fix a violation! And if it turns out that the fix is not obvious, you can start a thread of discussion on that review by adding a comment.
If you are not using Eclipse, you can still get notified when reviews are assigned to you. Just log into Sonar web application with your account and go to "My Profile" page to activate the email notification for reviews. This way, you won't miss a single review assigned to you! Actually, you should probably activate email notification in both cases: indeed, if you created a review and assigned it to someone else, you may want to know if the review has been solved, or if the developer added comments on it.
And what about reviews that have been fixed?
Sonar handles code quality for you, but it also makes sure that fixed reviews have correctly been handled. During the next analysis, for each fixed review, if its corresponding violation has actually disappeared, Sonar will set the review to "closed". If not, Sonar will reopen the review: in the morning, you will then see it again in your task list (or receive a mail) with the "reopened" status.
If you want to monitor more reviews - not only yours, you can use the Sonar review service that allows you to query reviews against their author, assignee, status, resolution, corresponding project or id.
That is it! This is how we are using differential views and manual reviews to run an effective continuous improvement process. Of course, you can adapt it - or even have a different one, to meet your needs. But keep in mind that the most important is to be sure that technical debt is under control!
More features are coming to support Continuous Inspection further: create reviews on any code, filtering newly created violations by developer... Stay tuned!