Code quality stamp

--- 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: * *Red*: the software is **dangerous** and **unreliable**. Its use is not recommended * *Orange*: The software can be used, but it is not **fully** certified * *Green*: The software has been **entirely** certified, so its use is recommended The minimal set of requirements a software **must** satisfy to obtain the *orange* color is: * No memory faults detected * No undefined behaviors * No known security issues * A code coverage $\geq 60\%$ To obtain a *green* 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 *red* 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