Programming Style metrics

Description

This section will provide detailed information about the different rules that measure and describe the quality of the code. It is necessary to understand that each of the rules explained in the following sections will be executed in an automated way by the Sonar tool.

The result of this automated analysis is a set of issues that are associated to an specific line and column on each file of code.

The following image shows and issue raised up by the execution of a rule. The file AuthenticationConnectorService.java generates an issue in the line 3, column 0 due to the rule "Unused import".

This image is a capture of the Sonar tool web site. Is important to remark that the information box linked to the issue gives information about the criticality of the issue and the technical debt generated by the own issue.

Rules 0

It is necessary to understand that each programming language has a different set of rules, but all of them are grouped into eight main categories. Wikipedia defines these categories as:

  • Reusability: in computer science and software engineering, reusability is the use of existing assets in some form within the software product development process. Subroutines or functions are the simplest form of reuse. A chunk of code is regularly organized using modules or namespaces into layers.

  • Portability: the software codebase feature to be able to reuse the existing code instead of creating new code when moving software from an environment to another.

  • Maintanability: the ease with which a product can be maintained in order to: correct defects, meet new requirements make future maintenance easier, or cope with a changed environment.

  • Security: rules that will flag anything suspicious, and leave it to the human security auditor to cull the false positives and sent the real issues for remediation.

  • Efficiency: rules that raise up possible defects or bugs that affect to the performance of the application.

  • Changeability: rules that measure the different attributes that bear on the effort needed to make modifications to the code.

  • Reliability: the ability of a system or component to perform its required functions under stated conditions for a specified period of time.

  • Testability: measures the ability of a code to be tested.

The same rules can be categorized depending on the source or convention that creates the rule. Once again, the rules depends on the programming language, so there are some sources not presented in all languages.

Depending on the source of the rule, Sonar has the following groups:

  • bug: something is wrong and it will probably affect production.

  • pitfall: nothing is wrong yet, but something could go wrong in the future; a trap has been set for the next guy, he'll probably fall into it and screw up the code.

  • clumsy: extra steps are used to accomplish something that could be done more clearly and concisely (e.g.: calling .toString() on a String).

  • convention: coding conventions - typically formatting, naming, whitespace...

  • misra: relates to a rule in one of the MISRA standards. While the MISRA rules are primarily about C and C++, many of them are not language-specific (E.G. don't use a float as a loop counter) but are simply good programming practices. That's why you'll see these tags on non-C/C++ rules.

  • unused: unused code, e.g.: a private variable that is never used.

  • cwe: relates to a rule in the Common Weakness Enumeration.

  • suspicious: it is not guaranteed that this is a bug, but it looks suspiciously like one. At the very least, the code should be re-examined & likely refactored for clarity.

  • cert: relates to a rule in a CERT standard. There are currently three CERT standards: C, C++, and Java. Many of these rules are not language-specific, but are good programming practices. That's why you'll see this tag on non-C/C++, Java rules.

  • security: it is not guaranteed that this is a bug, but it looks suspiciously like one. At the very least, the code should be re-examined & likely refactored for clarity.

Each rule is associated to a Severity level. The five standard levels of the Sonar issues are:

  • Blocker
  • Critical
  • Major
  • Minor
  • Info

Example of set of rules for one programming language:

Rules 1

Each rule has an extended description and examples associated for a better understanding of the rule:

Rules 2