This page will describe the different metrics that are available and tracked by Sonar. We will cover the following topics.

Code duplication

Code duplication is very hard to define. It generally falls within one of these definitions.

1. Identical code fragments except for variations in whitespace (may be also variations in layout) and comments.
2. Structurally / syntactically identical fragments except for variations in identifiers, literals, types, layout and comments. The reserved words and the sentence structures are essentially the same.
3. As previous, but with further modifications – statements can be changed, added and / or deleted in addition to variations in identifiers, literals, types, layout and comments.
4. Code fragments that perform the same computation but implemented through different syntactic variants.

Why care?

• Propagation of bugs: if a code fragment contains a bug and this fragment is copied, then the bug will exist in all pasted fragments. More generally, duplicating code will also duplicate the associated technical debt.
• Increased maintenance cost: any maintenance required on a copied code fragments will certainly need to be applied on the pasted ones, i.e. duplication multiplies the work to be done.
• Increased time to understand and thus to improve/modify existing system if it contains a lot of duplications, because differences must be studied by developers before modifications.
• As an indicator of a bad design, lack of good inheritance structure or abstraction.
• As an indicator about copyright infringement.

How to see it?

Again, Sonar has the tools for you to see these duplicated blocks.

Package Tangle Index

This metric tells you how many cycles exist between different Java packages. A cycle is defined as a circular dependency between two packages, one depending on the other and vice versa.

Why care?

• Tells you how likely making a change will break something; have unforeseen consequences.
• Makes refactoring very difficult

How it happens

Let's take the example of a program developed with the Domain Driven Design pattern. We start off with 3 layers.

• DAO
• Repository
• Service Layer

Transaction logic is put in the service layer. Starts absorbing business rules. So we push it down further into the model. Service layer seems pristine and focuses on one thing.

But then more requirements come in. Model relationships must be implemented. (ie. Line items vs. orders) We want to find all line items for a given order. The model starts depending on repository

    Service -> Repo -> Model -> Repo

How to see it?

Sonar calls these Directory Tangle Index. Anything above the downwards diagonal is a circular dependency.

How to fix it

Click on one of the red value in the cycle matrix. It will highlight the offending counterpart in the corresponding package.

A list of files is displayed. These are where the dependencies must be cut.

Code complexity

It is the cyclomatic complexity, also known as McCabe metric. Whenever the control flow of a function splits, the complexity counter gets incremented by one. Each function has a minimum complexity of 1.

Or. A measurement of the intricacy of a program module based on the number of repetitive cycles or loops that are made in the program logic. It is used as a general measure of complexity for software quality control as well as to determine the number of testing procedures

Why care?

• How many outcomes for a given piece of code?
• Outcomes create behaviors. Each is a possible regression.

How is it calculated?

public void process(Car myCar){          // +1
    if(myCar.isNotMine()){               // +1
         return;                         // +1
    }
    car.paint("red");
    car.changeWheel();
    while(car.hasGazol() && car.getDriver().isNotStressed()){   // +2
         car.drive();
    }
    return;
}

How to track this on Sonar?

Each project has a complexity analysis tool. ie: kettle-core.

• Total Complexity
• Complexity per file
• Complexity per class
• Complexity per function