Sonar collects and analyzes source code, measuring quality and providing reports for your projects. It combines static and dynamic analysis tools and enables quality to be measured continuously over time. More than 600 code rules are incorporated into the platform, checking the code from different perspectives.

Rules are separated into different logical groups and each one contributes at a different level towards the overall quality of the project in case. Analysis results, code violations, and historical data are all available and accessible through a well-thought-out user interface consisting of different components, with each one serving and fulfilling different needs and scopes.

The Sonar platform analyzes source code from different aspects. To achieve this, Sonar drills down to your code layer by layer, moving from module level down to class level. Picture this as a vertical movement through your source code from top to bottom components. At each level, Sonar performs both static and dynamic analysis producing metric values and statistics, revealing problematic areas in the source that require inspection or improvement. The analysis is not a monolithic procedure but examines code from different perspectives, introducing the concept of axes of quality. The results are then interpreted and consolidated in a very informative and visually appealing dashboard, enabling you to form an opinion about defective code and quality testing over projects. You can now take educated decisions as to where to start fixing things in a cost-effective manner, reducing the technical debt.

Although Sonar can be run as a one-off auditor, where the platform really shines is when you have it track and check your source code continuously. While a single inspection proves to be useful at times, it does not make the most out of the platform. The intended use is to have Sonar integrated into the team's development process, exploiting the platform's true capabilities.

If all these sound complex and advanced, they are not. It is a matter of a single download and running a script to have Sonar up and running, waiting to assess our code. Afterward, we can choose among different methods of how to import projects into the platform for analysis.

What makes Sonar really stand out is that it not only provides metrics and statistics about your code but translates these nondescript values to real business values such as risk and technical debt. This conversion plays a major role in the philosophy of the platform enabling a new business dimension to unfold, which is invaluable to project management. Sonar not only addresses to core developers and programmers but to project managers and even higher managerial levels as well, due to the management aspect it offers. This concept is strengthened more by Sonar's enhanced reporting capabilities and multiple views addressing source code from different perspectives.

From a managerial perspective, transparent and continuous access on historical data enables the manager to ask the right questions.

To better illustrate this, the following are some possible cases discussing quality and source code matters based on feedback from Sonar, either visual or textual:

Case 1: Complexity has jumped up lately; should we further examine the design and implementation of the recently added features? (Notice the line that represents overall complexity increasing close to 9.000.)

Case 2: Many major violations popped up during the last iteration. Are things moving too fast? Is the team taking more than it can handle? What about pace? (Sonar reports 589 major code violations.)

Case 3: Documentation is lacking and team composition is about to change. Let us clarify and better explain what our code is about. At least the public API! (Big red boxes represent undocumented public APIs.)

Sonar in the development environment acts as a quality management center. It is the place of reference when code quality matters arise, and sessions with team members drilling down views, exploring deficiencies and discussing software design and its implementation are not uncommon. The ease of the installation process and the broad accessibility by the web interface make it a perfect choice to inspect and share code quality among managers and developers.

An extra step is added to the developers' lifecycle, that of quality review and inspection. After updating and committing code, tests are executed within the context of the build server, producing a fresh artifact. Then, Sonar takes over collecting and analyzing source code and test results. Once the analysis process is complete, the Sonar dashboard is updated with inspection data reflecting the latest changes.

It is vital not to force Sonar into the development process but let the team embrace it.

Let us put technical details and issues aside for a moment and focus more on the psychological aspect of this process as a whole. There is no more rewarding experience for a developer than watching the results of his/her work on a daily basis, experiencing how his/her actions directly reflect upon the improvisation of the final product. Eventually, Sonar proves to be an essential part of a development setup, while the whole process becomes second nature to the developer.

There is one obstacle though that every development team will meet, that of the fear barrier and how to get over it. And by fear, we mean the fear to expose the quality of team members' source code, or most importantly the lack of it. And this is perfectly normal and expected.