Code quality with SonarQube on PHP projects. History of one refactoring.

We all like buying high quality products.
We all believe that we make high quality products in our job.
And if this is easy to check the quality of a material thing – it somehow seems to be a problem to verify the quality of a product that was made by a programmer.
First of all we need to admit, that the main product of programmer’s work is Сode.

Code is primary on a project. A possibility of the project to be “healthy” and “stable” strictly depends on the quality of code. With the growth of the project and development qualification every programmer comes to the necessity of finding a tool. A tool that helps to improve code quality and to make it stable.

Our team found a great thing for it. And it is called “SonarQube” (http://sonarqube.org)

SonarQube is a free tool for collecting statistics about project code. Using it on the project allows to:
- reduce risks – SonarQube platform enables its users to automatically discover existing bugs and provides possibilities of their removal before code deploying to the production level.
- increase code stability – using SonarQube lets control “technical debt” of the project by analyzing such metrics as code duplication, code complexity, potential bugs and so on. It allows to analyze the coverage of the code by unit testing which means a lot for project stability.
- increase productivity of developers’ work. Redundancy that is detected in advance can significantly reduce the amount of time development that team spends on code analysis. It especially works for staff turnover cases.

We have to admit that SonarQube tools are useful both for developers and project managers.
So we decided to implement SonarQube analysis in our existing and working PHP project that has already been being developed for two years. Let’s start!

First part. Analysis.

The SonarQube tool was installed to a developer’s machine. It uses JVM (Java Virtual Machine – Oracle JRE) and also needs MySQL Database as a prerequisite. Additionally a “sonar-runner” was set up. This is one of the six available analysis methods. Also a PHP plugin for SonarQube was also installed since we have a PHP project to analyze.

We are not describing the whole process of SonarQube installation – it’s complicated enough, however we are sure that your team will succeed.

Analysis is usually performed by:

  1. Sonar server start: sudo /opt/sonar/bin/linux-x86-64/sonar.sh start
  2. “Sonar-runner” analysis launching from the directory where the code is placed sonar-runner
  3. Result revision with SonarQube WEB interface. http://localhost:9000/sonar/

First we decided to analyze the project condition at two stages: in August, 2014 and in July, 2015.

See the picture below.

a) August, 2014

b) July, 2015

sonarqube_starting point

We put the results of matching in the table:

technical debt

We can see from the “Lines of Code” category that our project has grown by about 50% within the last year. But this is a quantity metric, and it isn’t very important.  We’d particularly like to dwell on complexity metric. Metric that is also called “cyclomatic complexity” and Sonar has its own patented method of complexity calculation.

 Cyclomatic complexity of a program — structured (or topological) measure of complexity of a program used for quality measuring of a code, based on the methods of statistical analysis.  (https://goo.gl/c2QfYM)

In a nutshell, total complexity shows how much logic was implemented in the program. On the other hand – average value of cyclomatic complexity (CC) per method or per class  is a metric that actually counts. The increase of average CC shows a loss of integrity.

CC average

In our case:

Moving forward to the second part of the Sonar screen:

a) August, 2014

b) July, 2015

SQALE rating

 

As you can see in the screenshot we have a new definition here : technical debt.
In the SonarQube technical debt describes facts of mismatching of the code toward the standards of coding.

SQALE Rating –  health rating based on its density of technical debt, which is basically the effort to fix it versus the effort that has already gone into it. (http://goo.gl/UwhWkJ)

We can say that rating is based on the value of time (or money) that is requested to write every single line of code.
SQALE Rating = TechDebt /(Lines of code * Average price of writing one line of code );
Another meaning of SQALE Rating – is percent ratio of time needed to fix all found mistakes to the time that was already spent for writing the code. In our case SQALE Rating is 4.2% that is less than 10% (everything below 10% gets an “A” category of technical debt complexity)

So, technical debt:

technical debt2

Issues are mistakes or code zones that SonarQube recognizes as errors.

The analysis showed us cyclomatic complexity metric increase, so we decided to refactor our code.

Second part. Refactoring.

Issues in the SonarQube were grouped by tags. And in the picture below you can see those tags. We caught an increase of issues so as a result we had a bigger technical debt according to the metrics above.

tag

Code convention issues are parts of code that do not match the coding standards of PHP language. This was the largest group of mistakes in our case. The mistakes mainly consisted of incorrectly named variables. See the screenshot below.

rename local variable

As you can see our developers tend to use “_” (underline sign) in variable names – and this goes against the code standards. You can also see that SonarQube estimates such mistakes within 2 minutes of programmers’ work. At a first glance such mistakes are easy to correct, however we recommend estimating them more accurately, as we underrated them at a start.
It took us some patience to begin refactoring code using a simple search and replace functionality of our IDE. We started naming variables according to Zend coding standards (http://goo.gl/SyEZzQ)
So, a piece of advice number 1: name variables according to coding standards.

The second big group of problems are so called “brain-overload” issues. See the picture below:

brain overload

Here we had mismatches with coding standards again. According to SonarQube file that has more than 1000 of lines, it becomes a “brain-overload” issue. So, a piece of advice number 2: don’t make files longer than 1000 lines.

Also according to SonarQube :

  • A class that has more than 20 methods becomes a “brain-overload” issue.
  • A function that has more than 100 lines becomes a “brain-overload” issue.

A piece of advice number 3: every part of code should be short and simple.

The usual issue for our project is a high level of average function cyclomatic complexity. We did some refactoring, however it is the most difficult issue to fix. Be careful: fixing it can cause long breaks in the development. Also we found it hard to simplify the code while using the Agile development approach – every day each part of code can get a new meaning and functionality. Changes in new features implementation schedule put us off refactoring process twice.

A piece of advice number 4: agree upon the planned time to spend on refactoring with stakeholders.

There are some other Sonar tips:

  • Sonar recognizes a commented out code as “unused issue” and estimates it as an additional 20-minute technical debt.
  • Single line of a commented out code that is placed in line with normal code adds 1 minute to technical debt.

Let’s sum up our basic recommendations:

● Name variables according to coding standards.
● Don’t make files longer than 1000 lines.
● Every piece of code should be short and simple.
● Agree upon the planned time to spend on refactoring with stakeholders.

Third part. Results.

First of all we’ve made a great start for future project stabilization. Programmers can look at their code on a bigger scale and understand it globally.
The second and the main result is that metrics of complexity found by SonarQube enabled us to begin another important task: coming to the Test Driven Development – a way of code writing when every function or method can be tested with a Unit Test. This programming approach can’t afford too complicated functions – so one day we can totally reduce the Cyclomatic Complexity of our projects. However TDD and our Continuous Integration (CI) solutions on our projects are the topics for a separate article.
The third result of our work: SonarQube is used by our project managers. Yet, it is the best solution for non-technical specialists to control the state of code. Who knows, maybe we shouldn’t have let the cat out of the bag ;)

The most curious readers can examine the final numbers of refactoring for our project below:

numbers of refactoring

… and the second part of the screenshot:

numbers of refactoring2

summary table

And the summary on complexity:

summary table2

Time report about the project state in every moment of the refactoring process:

refactoring process refactoring process2

refactoring process2

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>