Lao Li share: 5 standards for measuring software quality

1. Sourc Lines of Code (SLOC)
Counting the number of code lines can be the simplest method. It can reflect the size of the software, to provide some data support for the development and planning of the project. For example, we count the number of lines of code once a month, and we can get a general idea of how the project is going. Of course, this is not a trustworthy standard, because there are refactoring and design factors.

SLOC is best to count Source Logical line of Code (Slloc) for more accurate information. Logical code lines does not contain blank lines, single parenthesis lines, and comment lines. You can easily count Slloc by Metrics such a tool.

The number of lines of code should not be used to measure development efficiency. Otherwise it is easy to create repetitive, hard-to-maintain and unprofessional code.

2. Bugs per code_section/module/time_period
Issue tracking is a critical step in ensuring testing and maintainability. If all the questions (bugs) are tracked, each code unit, each module, or a specific time (day, week, month ...). Problems are easily counted (e.g. Mantis tools). When we have this data, the root cause of the problem can be found and processed as early as possible.

The number of questions can be a standard for measuring development quality, but it must be used with caution. If you overemphasize the number of bugs, then the key to development and testing will be very tense. In an efficient company, all employees should be in harmony.

In order to better evaluate the quality of the code. Bugs can be divided into low, medium, and high three levels, because their importance and repair costs are not the same.

3. Code Coverage
The code coverage indicates the extent to which the codes have been tested. There are many tools that can automatically count this data, such as Cobertura.

The Code coverage does not describe the overall quality of the unit tests, but it can explain the coverage of the tests. It can be used together with some other indicators to measure the quality of the software. Of course, we also need to constantly review the unit test code and the use cases of integration testing.

4. Design/development contraints
There are many design rules in software development, such as:
-Length of class/method
-Number of methods/attributes
-Number of parameters for the method
-Special values and the use of strings
-scale of annotations
These rules are important metrics to ensure code readability and maintainability. The development team should choose some or all of the rules to implement (e.g. Maven PMD plugin). This will help improve the quality of your software products.

5. Cyclomatic complexity (loop complexity)
The loop complexity is listed separately because it is not the same as the other design-side. Loop complexity is about code implementation and execution. It can also be automatically calculated using tools such as PMD.

This value is the number of independent code execution paths. For example:

Cyclomatic complexity = E (edges)-N (nodes) + 2P (exit nodes)
So, cyc.cmp. = 8-7 + 2*1 = 3

You can also see that there are three different paths from the starting point to the end point. This value is often calculated for the method. Depending on the project type, we can set the upper limit for this value, such as 6, 8, or 10.

An indicator does not describe the quality of the whole project. Using more indicators will give you a more comprehensive understanding of the quality of your project.

Lao Li share: 5 standards for measuring software quality