Managing code quality

It’s fair to say that the quality of your code has a direct correlation to the success of your product.   Products crafted to a high quality using proven techniques and industry accepted standards have a better chance of succeeding.  This applies to any field; be it. car production, joinery and  most certainly software development.

Most computer programmers agree it is good practice to write code that follows a strict coding standard.  Common rules are accepted within the industry in relation to code quality: such as; keeping your functions and procedures small and simple; ensuring objects have high cohesion and low coupling; and, implementing principles like inheritance, encapsulation and polymorphism.  However, what we find within the software industry is these rules are well known; but, more often not followed.  This isn’t because rogue programmers are intentionally ignoring these principles, or, lazy, it is more the case that these things are difficult to do and equally difficult to measure.

There is hope.  Tools for automating code quality do exist.  If fact, the level of automation available from these code quality tools provide a vast array of reports for the development team.  In fact, I covered a code quality tool for JavaScript called JSLint within one of my previous posts.  Although JSLint is a great tool, it is only useful if you are writing in JavaScript.  So what if you need a tool that can cope with various languages; be it, Java, JavaScript, C, PHP, PL/SQL!

It is not uncommon for an organisation, or, an individual to require code quality management for multiple source code repositories written in different languages.  Does such a tool exist?  Yes.  Introducing sonar.  Sonar is an open platform to manage code quality.  The documentation on the official site includes installation instructions and much more – so I will not repeat this here.  But I will cover the basics.

After installing sonar, one must start the sonar software.  It can be started from the command line, by calling a batch file.  This batch file is called ‘StartSonar.bat’ and resides within the ‘\bin\arch\’ installation sub-directory e.g.


Sonar can take a while to start, but once started you can  log on to the management interface using browser.  The management interface is available on port 9000.  Thus, it is accessible via the URL http://localhost:9000.  The default screen includes a summary of any projects that you have previously analysed:

Default home screen for sonar

The information within this screen very useful.  The ‘Lines of code’ (LOC) and ‘Rule compliance’ column shows the rating and trends for each project analysed: hopefully this will show an upward compliance trend!  Drilling into a project reveals the specific details:

Drilling into  sonar project

The details summarized in this page are very useful.  When a project is analysed it is assessed using a default rule-set.  Sonar compares the source code for the project and compares it against the rule-set, looking for violations against common good practices.  Trends are provided for the violation count, including categorised violations.  Interesting statistics and analysis shows instants of duplicate code, percentage of commented code and the results of any unit tests!  Very powerful indeed.

Further drill downs reveal the detail of each.  For example, the following screen details the two critical violations noted above.

sonar violations

Using this information one can then refer the results back to the development team to rectify the findings.

The analysis is performed by running the tool ‘sonar-runner.bat’. This should be executed from the base directory of the source code.  The sonar-runner process expects one input: a properties file.  This file specifies properties such as the name and version of the project to be analysed, source code language and directory structure.  The format of the file is well documented on the official site so I will not go into the detail; however, an example follows:

sonar example properties file

The content of the file explicitly states the project key, name and version.  Additionally, the file contains a comma-separated list of the libraries which hold the source code to be analysed.  The final property defined is the language of the source code e.g. Java, JavaScript, C.  Once the properties file is present sonar-runner can be executed:

Example of running sonar runner against a JavaScript project

On completion the results are instantly available within the management interface:

Perfect source code

The above now shows the Chess project is 100% compliant with the rule-set.

As you can see this product is very powerful indeed.  In fact, the above only scratches the surface.  The sonar project allows much more; including, user-defined rule-sets, continues automated integration, unit test execution and plug-in driven extension model!


One thought on “Managing code quality

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s