Sonar Mythbusters

by fabrice bellingard|

    When I joined the Sonar team 6 months ago, I had heard and read - here and there - myths about Sonar. Though I knew some of them were incorrect, I have since then understood their historical reasons (functionalities that were missing back years ago) or the misunderstanding about what Sonar is about. So I have thought that time has come to shoot our own Sonar Mythbusters. For we know that myths die hard...

    Sonar is complementary to Findbugs!

    Sonar is definitely not "complementary" to Findbugs: it embarks Findbugs, as well as other well known static code analysis tools such as PMD or Checkstyle. Those tools are doing an excellent job in their own field, that's why Sonar includes them all in its core and correlates their result reports to leverage the benefits of using them.

    In other words, if you are already using tools like Findbugs, PMD or Checkstyle, Sonar will bring you the very same information plus much more!

    Sonar is simply an aggregator of existing tools!

    While this is true that Sonar collects results from external tools, the core of Sonar is built around its own technologies, the most famous one being Squid. Squid calculates metrics, parses byte-code and allows to develop specific rules to check violations on Java source code as well as on Java byte code. You might have read our blog post entry about dead code detection and calls to deprecated methods: this was implemented thanks to Squid functionalities.
    Sonar also embeds its own recognition language framework to be able to develop parsers for other languages, like for the existing freeware C plugin or the commercial Cobol plugin.

    I must build my project with Maven to use Sonar!

    Historically, Sonar has been built around Maven in order to leverage existing pieces of technology. Therefore, to run an analysis, it was necessary to have Maven installed on the box - even though you would not necessarily have to build your project with Maven.

    Since Sonar 2.6, this pre-requisite is now all over: you can launch a Sonar analysis either using Maven, a dedicated Ant task or a simple Java runner. We are currently working hard to complete the decoupling of Sonar from any build technology so that it is possible to develop other runners (Graddle for instance) or fully embed Sonar in IDEs (like the Sonar Eclipse plugin).

    I can analyse only Java projects!

    As mentioned, Sonar was historically built on top of Maven, which is a build technology for Java. Soon, we felt that Sonar could (and should!) be more than just a Java-centric technology: IT systems are built on top of several technologies, and every big company's application portfolio is heterogeneous. Even Java applications may contain code written in other languages such as Javascript... So we opened our platform and APIs to make it possible to extend Sonar.

    Today, with a growing forge of plugins, Sonar has the ability to analyse more and more languages: Java (out of the box), Cobol, PHP, .NET (C#), HTML (with JSP&JSF), Flex, Groovy, PL/SQL, VB6, Natural... and more to come soon!

    Sonar can only be used by technical guys!

    This is true that to install and configure Sonar and then to run an analysis on a project, you need to have some technical understanding of the environment. But we are talking about technical code quality here, right? I am sure you will find somebody around to give you a hand to set up a continuous integration server so that you just have to open your favorite web browser and watch Sonar dashboards. Since Sonar 2.4, you can even create your custom dashboards that suit your needs!

    Because Sonar is open source, I will get no support!

    The fact that we have chosen to develop Sonar with a community and to distribute it freely under a LGPL v3 license has nothing to do with the fact that support gets provided on the platform. The user and development mailing lists are very active, but you also can buy Professional Support directly from SonarSource if you prefer.

    I can't automatically assess the technical debt!

    At SonarSource, we started to talk about assessing automatically technical debt approximatively two years ago when releasing the first version of the Sonar Technical Debt plugin, which automatically computes - on every analysis - how much technical debt a project is in. It provides a simple but efficient widget that perfectly fits into a manager dashboard. This was our first step towards a more mature way to assess technical debt: the SQALE plugin was born in late 2010, offering a sound customizable quality model that conforms to ISO 9126 standard, along with new visualisations to help digging down the technical debt your project is in.

    Haven't seen the SQALE plugin in action yet? You can have a look at it on our Sonar public instance, or even better: you can ask for an evaluation license to give it a try on your own projects!

    I cannot do governance on my portfolio with Sonar!

    Well, as we previously said, Sonar has been first thought and designed to meet the needs and requirements of development teams. But as time goes, we are closing gaps to now tackle the governance side. The first step was to build a Portfolio Management plugin, which allows to organize projects according to your needs. You can for instance group them by business units, and therefore know which teams follow the best your quality requirements and which projects will cost you the most per business unit.

    Yes, but Sonar is not robust enough to handle big IT application portfolios, is it?

    As unbelievable as it can sound, Sonar is an open-source tool that can be installed in 2 minutes, is robust, stable and reliable enough to perform code analyses on large IT application portfolios. The biggest instance of Sonar we know contains 3,000+ projects representing more than 150 million lines of code across 4 languages analyzed on a daily basis and reporting to 20,000+ developers and to the whole management team.

    And you, do you think of other Sonar myths that we should definitely burry?