All covered with tests, absolutely all
The Agitar Software company offers a rather interesting metric to assess the quality of the program code. The formula with the unambiguous name CRAP allows you to assess whether the developer will exclaim “Oh crap!” After learning that he was happy to support the code.
Of course, there is no absolutely reliable way to determine whether a certain piece of code is “crappy” or not. However, it is intuitively clear that such a review is likely to receive an unnecessarily complicated, tangled code. And since writing automated tests (for example, using JUnit or PHPUnit) for confusing code is not a trivial thing, it usually turns out not to be covered with tests at all. The presence of unit-tests means not only monitoring the performance of the code, but also a more understandable architecture of the application, as well as the fact that the developers took care of the costs of support.
How it works
')
If you go into mathematics, the CRAP value (Change Risk Analysis and Prediction) for a single method, m, is calculated using the formula:
CRAP (m) = comp (m) ^ 2 * (1 - cov (m) / 100) ^ 3 + comp (m)
where comp (m) is the so-called cyclomatic complexity of method m, defined as the number of paths inside the method plus one, and cov (m) is the percentage of code covered by tests.
In other words, a low CRAP index means a relatively small risk when the code changes: the code is simple and its performance is well controlled by tests. A high index means that making changes is rather risky: the complexity of the code combined with a small number of tests gives a rather dangerous combination, you can be sure that something will break in the most unpredictable place. Thus, the CRAP-index can be lowered either by writing unit tests for complex code sections, or by using refactoring this complexity can be reduced. Of course, it’s preferable to have both, since the presence of tests helps to avoid errors during refactoring.
Crap4j
So far there is only one implementation of the CRAP formula, in the form of the crap4j Eclipse plugin for Java. As acknowledged by the developers themselves, all threshold values are purely experimental. The CRAP-index of a single method can vary from 1 (for the method of complexity 1, covered with tests for 100%) to fairly impressive numbers (for example, the method of complexity 100 without a single test will receive 10,100 points). It was decided, for a start, to use the threshold of 30 points as the border from which the crappy code begins. For example, methods with complexity 10, 75% covered with tests, are not yet considered as crap, as well as methods with complexity 2 without tests in general.
At the project level, statistics show the percentage of methods with a crap-index above 30. A project can have up to 5% of such methods (however, nothing prevents you from adopting your own threshold values). In addition, crap4j shows the so-called CRAP load - this is an estimate of the amount of work needed to correct crappy-methods, taking into account the missing number of tests and refactoring necessary for writing them.
Like any of the existing metrics, CRAP is, of course, not perfect. The code can be completely covered by useless tests, or contain a complex method, which, however, is easier to understand than the 3 more simple ones. Higher-level metrics that are oriented towards the application architecture (such as coupling and cohesion ) are not taken into account. Nevertheless, the formula provides enough useful information and an extensive field for experiments.
Crap4j Home | Eclipse Update Site | Enjoy!
More on the topic:
Pardon My French, But This Code Is CRAP
The Code CRAP Metric Hits the Fan - Introducing the crap4j Plug-in
Of course, there is no absolutely reliable way to determine whether a certain piece of code is “crappy” or not. However, it is intuitively clear that such a review is likely to receive an unnecessarily complicated, tangled code. And since writing automated tests (for example, using JUnit or PHPUnit) for confusing code is not a trivial thing, it usually turns out not to be covered with tests at all. The presence of unit-tests means not only monitoring the performance of the code, but also a more understandable architecture of the application, as well as the fact that the developers took care of the costs of support.
How it works
')
If you go into mathematics, the CRAP value (Change Risk Analysis and Prediction) for a single method, m, is calculated using the formula:
CRAP (m) = comp (m) ^ 2 * (1 - cov (m) / 100) ^ 3 + comp (m)
where comp (m) is the so-called cyclomatic complexity of method m, defined as the number of paths inside the method plus one, and cov (m) is the percentage of code covered by tests.
In other words, a low CRAP index means a relatively small risk when the code changes: the code is simple and its performance is well controlled by tests. A high index means that making changes is rather risky: the complexity of the code combined with a small number of tests gives a rather dangerous combination, you can be sure that something will break in the most unpredictable place. Thus, the CRAP-index can be lowered either by writing unit tests for complex code sections, or by using refactoring this complexity can be reduced. Of course, it’s preferable to have both, since the presence of tests helps to avoid errors during refactoring.
Crap4j
So far there is only one implementation of the CRAP formula, in the form of the crap4j Eclipse plugin for Java. As acknowledged by the developers themselves, all threshold values are purely experimental. The CRAP-index of a single method can vary from 1 (for the method of complexity 1, covered with tests for 100%) to fairly impressive numbers (for example, the method of complexity 100 without a single test will receive 10,100 points). It was decided, for a start, to use the threshold of 30 points as the border from which the crappy code begins. For example, methods with complexity 10, 75% covered with tests, are not yet considered as crap, as well as methods with complexity 2 without tests in general.
At the project level, statistics show the percentage of methods with a crap-index above 30. A project can have up to 5% of such methods (however, nothing prevents you from adopting your own threshold values). In addition, crap4j shows the so-called CRAP load - this is an estimate of the amount of work needed to correct crappy-methods, taking into account the missing number of tests and refactoring necessary for writing them.
Like any of the existing metrics, CRAP is, of course, not perfect. The code can be completely covered by useless tests, or contain a complex method, which, however, is easier to understand than the 3 more simple ones. Higher-level metrics that are oriented towards the application architecture (such as coupling and cohesion ) are not taken into account. Nevertheless, the formula provides enough useful information and an extensive field for experiments.
Crap4j Home | Eclipse Update Site | Enjoy!
More on the topic:
Pardon My French, But This Code Is CRAP
The Code CRAP Metric Hits the Fan - Introducing the crap4j Plug-in
Source: https://habr.com/ru/post/18118/
All Articles