---
# System prepended metadata

title: Code quality stamp
tags: [' wp2', Ideas]

---

---
tags: Ideas, wp2
title: Code quality stamp
---

Some metrics can only give information on the status of a code or the bad practices adopted during the development phase, while other ones identify the faults present in a software. For this reason, we have grouped the metrics in two categories: *Fault metrics* and *Quality metrics*. Then, we have used those categories to define the stamps that allow to determine the quality level of a software.

## Metrics Categories

Some of the metrics described above identifies faults that can lead to security problems or make a software unusable because of crashes, while other ones aim at detecting the parts of code that possibly hide deeper problems and **may** transform into bugs and dangers in future refactors.

This distinction leads to define two categories:

* *Fault metrics*
* *Code quality metrics*

*Fault metrics* describe the *objective* defects present in a software, such as memory faults, security issues, and the presence of a limited test suite. Those metrics are called *static* when are computed analyzing a code in search of errors, while are *dynamic* when count the number of passed unit and integration tests, estimate the percentage of code covered by the test suite, and detect some other faults at runtime. Practically, *Fault metrics* represent every *unambiguous* problem that could arise in a code and, consequently, in the final binary.

*Code quality metrics*, instead, identify the portions of a code that are complex to understand at first glance as well as *code smells*, thus weaknesses in design that **may** slow down the development process or increase the risk of bugs and failures in the future. Practically, this category provides some indications to a developer in order to improve code quality, more specifically the static metrics such as code complexity and code clarity. Those metrics are usually computed by *heuristic* algorithms that indicate to a developer when it is necessary to refactor the code.

## Software Quality Certification

The software quality certification is a procedure that a developer **must** undertake to guarantee to users, third-parties, and other developers too, that a software is reliable, secure, well tested, and with a code written in a comprehensible way.

This certification procedure consists of assigning a stamp to a software that satisfy a list of requirements, each of them based on the *Fault metrics* category. The color of a stamp then represents set of requirements satisfied by a developer. The stamp is called *Fault Stamp* and it is **mandatory**.

### Fault Stamp

The main task for the *Fault Stamp* consists of evaluating the security and reliability of a software.

To do so, a developer **must** compute the *Fault metrics* and present their values alongside the list of tools used to obtain them. 
It is strongly recommended to save those metrics in a machine-readable format in order to simplify a possible future processing, but any other human-comprehensible format (just to cite few: HTML, MarkDown, Yaml) can also be valid.

The colors associated to this stamp are based on a traffic-light system:

* <span style="color:red">*Red*</span>: the software is **dangerous** and **unreliable**. Its use is not recommended
* <span style="color:orange">*Orange*</span>: The software can be used, but it is not **fully** certified
* <span style="color:green">*Green*</span>: The software has been **entirely** certified, so its use is recommended

The minimal set of requirements a software **must** satisfy to obtain the <span style="color:orange">*orange*</span> color is:

* No memory faults detected
* No undefined behaviors
* No known security issues
* A code coverage $\geq 60\%$

To obtain a <span style="color:green">*green*</span> color instead:

* No memory faults detected
* No undefined behaviors
* No known security issues
* A code coverage $\geq 80\%$

All other possible combinations lead to a <span style="color:red">*red*</span> color.

We would like to clarify that those requirements should not be interpreted as if the software is **free** by any faults, but rather that the tools used by a developer for its certification have **not** detected any problem.

Some programming languages could implement out of box features that prevent certain classes of mistakes. In that case, a developer **must** provide an official reference to the programming language specification in order to skip certain workflow steps.

### Code Quality Evaluation