How can we evaluate whether software writing is good or bad?

Software itself is a kind of Fixed Thinking. Therefore, in essence, software cannot be measured.

However, this does not mean that the software does not require measurement, but that most of the measurements in the software have a certain limit.

When various metric data are applied, the results are counterproductive.

 

In this article, we will examine the existing methods for measuring software (Note: This article mainly examines others' methods, not my own ).

It may not be comprehensive. You are welcome to add any deficiencies.

The measurement of "Visually visible quality attributes" of the software is relatively simple, such as Bug rate and performance.

Here we mainly focus on the inherent and invisible quality attributes of software.

 

• Circle complexity

 

The circle complexity is mainly used to measure functions or methods. The circle complexity description can be found in code Daquan.

About the circle complexity: Tom McCabe once suggested using the following method to measure the complexity. In this method, the decision Point (demo-points) in the subroutine must be calculated to calculate the complexity. The rules are as follows:

 

1. 1. From the first line of the function to the next through the program
   2. Once the following keywords or similar words are met, add 1: if, while, repeat, for, and, or
   3. Add 1 to each case in the case statement -- Steve McConell code book

 

Many static analysis tools directly provide measurements on the complexity of the circle. The complexity of the circle itself is ambiguous and is a rare indicator. Code above 15 is basically hard to understand.

However, the circle complexity is more suitable for the measurement encoding results, but not for the high-level design.

 

• Response set

 

A response set is the number of functions directly called by each method of the class. The response set should undoubtedly be as small as possible. According to the dimetel rule, any method of an object should only call methods in the following situations.

Class Demeter
{
Private:
A *;
Int func ();
Public:
//...
Void example (B & B );
Void Demeter: example (B & B)
{
C c;
Int f = func (); // <---- class's own Method
B. invert (); // <---- Method for passing in the parameter. Of course, the parameter itself may also be a function.
A = new ();
A-> setActive (); // <--- method of the created object
C. print (); // <--- method of creating and returning all objects
}
};

--- Excerpt from the programmer's cultivation path

 

• Link cohesion (H)

 

When measuring a package, you can divide the number of classes in the package by the total number of classes in the package. The ratio is used to indicate the cohesion of the package. If R is used to represent the number of class relationships in the package, N is used to represent the total number of classes in the package. So:

H = (R + 1)/N

• Instability (I)

Instability is calculated by the input Coupling Degree (Ca) and the output coupling degree (Ce.

The package input Coupling Degree refers to the number of classes in the package, which is external to the package but dependent on the number of classes in the package.

The package output coupling degree refers to the number of classes in the package that depend on the package's external classes.

In this way, I = Ce/(Ca + Ce)

 

• Abstraction ()

 

The abstraction of a package is calculated by the number of abstract classes and the number of classes in the package.

If the total number of classes in the package is Nc and the number of abstract classes is Na, the Abstraction Level A = Na/Nc

 

For more information about relationship cohesion (H), instability (H), and abstraction (H), see Agile Software Development: Principles, models, and practices.

 

These metrics are undoubtedly meaningful and can be used to evaluate whether software writing is good or bad, but they do not solve the following problem:
If a scheme has a good performance in relational cohesion (H), instability (H), and abstraction (H), does the complexity increase? If the complexity increases, isn't the complexity of this extra expenditure worth it?

If we think that complexity is the fundamental problem of software, simplifying the software is the most critical mission (more important than flexibility) to meet the requirements ). In this case, how should we measure the complexity of the software?

This is a topic that needs to be further discussed. I will share it with you later.