Metrics

Metrics :

• There are many code metrics, some of them measure code quality and others just prepare information about code situations.
• Metrics that measure code quality:
  Afferent Coupling
  Class Coupling
  Cyclomatic Complexity
  Depth of Inheritance
  Efferent Coupling
  Instability Index
  Maintainability Index
• Metrics that do not measure code quality:
  Code Coverage
  Lines of Code

Code Metrics Synonyms :

• Many code metrics have synonym as following:
  Lines of Code (LOC): Source Lines of Code (SLOC)
  Class Coupling: Coupling Between Objects (CBO)
  Depth of Inheritance: Depth of Inheritance Tree (DIT)
  Efferent Coupling (Ce): Outgoing Dependencies
  Afferent Coupling (Ca): Incoming Dependencies
  Cyclomatic Complexity: Program Complexity

Class Coupling :

• Class coupling is a measure of the dependencies a class has on other classes.
• Coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.
• A measure of how many classes a single class uses. High is bad, low is good.
• The code metric class coupling measures the coupling to unique classes through parameters, local variables, return types, method calls, generic or template instantiations, base classes, interface implementations, fields defined on external types, and attribute decoration.
• High class coupling indicates a design that is difficult to reuse and maintain because of its many inter dependencies on other types.
• When this coupling is high, we may assume that the software modules are interdependent, i.e., they cannot function without the other.
• Class coupling measures each class only once for this metric no matter how many times it gets used.
• Class Coupling is Code Metric which checks the Code Health.

Code Coverage :

• Code coverage is a measure used to describe the degree to which the source code of a program is executed or exercised when a particular test suite runs. Note that 100% coverage will not assert that the quality is perfect, but a low number will tell you that you have insufficient testing and the source code is error‐prone. In addition, for code coverage calculation all unit tests should be passed.
• Code coverage is a measure which describes the degree of which the source code of the program has been tested. It is one form of white box testing which finds the areas of the program which have been exercised by a set of test cases.
• Code Coverage is a measurement indicating the amount of product code that is exercised by tests.

Code Coverage drawbacks :

• There is a tendency as a shortage to write tests in order to just increase the code coverage rather than discovering bugs. In addition, code coverage does not ensure that the most sensitive and important portions of the code are tested and does not necessarily provide functional coverage.
• Code coverage does not necessarily provide functional coverage.
• Code coverage could create incentives to write tests that simply increase coverage, rather than tests that find bus without increasing coverage.
• Code coverage does not ensure that the most important or highest risk areas of the code are being excised by tests.
• One of the drawbacks of code coverage could be that there might be incentives to write tests that simply increase code coverage, rather than tests that find bugs without increasing coverage.
• Code coverage does not represent or talk about the quality of the code which is being exercised. It just addresses “How much” code not “Which” code.

Code Coverage practice :

• 90% of Unit test cases passed with 70% Code Coverage. This means 10 % of Unit Tests Cases failed, only 70 % of your code is checked and 30% of your code remains to be checked. / validated using unit or other kind of test.

Code coverage types :

• 1. condition : Modified condition/decision coverage.
• 2. statement : Statement coverage and Block coverage.
• 3. path : Branch coverage.
• 4. function : Function coverage and Function call coverage.

Cyclomatic Complexity :

• Code complexity measure based on the # of independent logical branches through a code base. The number of “if” statements, loops and switch cases in a code is represented by Cyclomatic complexity.
• Cyclomatic complexity is expressed as a simple integer (nombre entier).
• Cyclomatic Complexity: Measures the number of linearly independent paths through a program’s source code
• Cyclomatic complexity represents the number of unique paths through your code.
• Cyclomatic Complexity is Code Metric which checks the Code Health.

Depth of inheritance :

• Depth of Inheritance indicates the number of different classes that inherit from one another, all the way back to the base class.
• Depth of Inheritance is similar to class coupling in that a change in a base class can affect any of its inherited classes.
• Depth of Inheritance is similar to class coupling however the difference is that in Depth of Inheritance, a base class can affect any of its inherited classes.
• Depth of Inheritance implies the maximum length from the node to the root of a code tree. A low number for depth implies less complexity but also the possibility of less code reuse through inheritance. In addition, a high number for depth implies more potential for code reuse through inheritance but also higher complexity with a higher probability of errors in the code. It is a code quality metric.
• Depth of Inheritance is Code Metric which checks the Code Health.
• The deeper the depth of inheritance, the more potential there is for causing breaking changes in the code when modifying a base class.

Function points :

• The function point is a “unit of measurement” to express the amount of business functionality an information system (as a product) provides to a user. Function points are used to compute a functional size measurement (FSM) of software. The cost (in dollars or hours) of a single unit is calculated from past projects.
• The use of function points in favor of lines of code seek to address several additional issues:
  The risk of “inflation” of the created lines of code, and thus reducing the value of the measurement system, if developers are incentivized to be more productive. FP advocates refer to this as measuring the size of the solution instead of the size of the problem.
  Lines of Code (LOC) measures reward low level languages because more lines of code are needed to deliver a similar amount of functionality to a higher level language. C. Jones offers a method of correcting this in his work.
  LOC measures are not useful during early project phases where estimating the number of lines of code that will be delivered is challenging. However, Function Points can be derived from requirements and therefore are useful in methods such as estimation by proxy.

Coupling and Cohesion :

• In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.
• Coupling is usually contrasted with cohesion. Low coupling often correlates with high cohesion, and vice versa. Low coupling is often thought to be a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability.

Cohesion :

• Cohesion is a measure of the degree to which the responsibilities of a single module or a component form a meaningful unit.
• Cohesion describes how related the functions within a single module are. High is better.
• Cohesion makes software easier to understand, reduces the effects a change on one part of the system has on the rest of the system, and it allows us to reuse code within our application.

Module Coupling :

• Module coupling is one of the most important metrics in software design. It gives us the clue how good we are at using types defined in other modules. There are two kinds of couplings – efferent and afferent.
• Whenever a class is coupled to a class from another module, we say that its containing module is also coupled to the other module. Module coupling is measured by counting classes from other modules that it is coupled with. Of course, one class may couple with another class from the same module. Such pair of classes does not contribute to module coupling because it evens out.
• In other words, we can measure efferent coupling of a module as the count of classes from other modules that classes from this module know about. Conversely, afferent coupling of a module is the count of classes it contains that classes from other modules know about.
• Total coupling of a module is calculated by summing up its efferent and afferent coupling.

Afferent Coupling :

• The number of classes in other packages that depend upon classes within the package is an indicator of the package’s responsibility. Afferent couplings signal inward.
• Afferent couplings (Ca): The number of classes in other packages that depend upon classes within the package is an indicator of the package’s responsibility.
• Incoming : Afferent (incoming) couplings. Who depends on you.
• Measure of how many other packages use a specific package.
• Incoming dependencies.
• Afferent couplings signal inward.
• Afferent coupling measures how many classes depend on a given class and has the following characteristics:
  • Classes with high afferent will affect other classes when changes are made.
  • A large afferent coupling can indicate that you should reconsider the responsibilities of the class, because It will be very difficult to make changes to this class later when so many other classes are dependent on it
• It is a code quality metric

Efferent Coupling :

• Efferent coupling is a coupling metric in software development. It measures the number of data types a class knows about.
• This includes inheritance, interface implementation, parameter types, variable types, and exceptions.
• This has also been referred to by Robert C. Martin as the Fan-out stability metric which in his book Clean Architecture he describes as Outgoing dependencies. This metric identifies the number of classes inside this component that depend on classes outside the component.
• This metric is often used to calculate instability of a component in software architecture as I = Fan-out / (Fan-in + Fan-out). This metric has a range [0,1]. I = 0 is maximally stable while I = 1 is maximally unstable.
• Instability of a class or a module is the ratio between its efferent coupling and total coupling. Obviously, instability is a value between 0 and 1, inclusive.
• Instability of zero means that the class or module is absolutely stable. It depends on nobody, everybody depend on it. The term “stable” itself indicates the desired quality of such class or module. We want such class never to change, we want it to be absolutely stable, or otherwise we will have to maintain other classes that depend on it whenever we change it.
• Instability equal to one means that the class or module is absolutely instable. It depends on other classes and must be changed when other classes are changed. On the other hand, changing this class means nothing to others. That is why we call it “absolutely instable” – we can change it liberally and no harm will be done to other parts of the system.
• Efferent coupling measures the number of classes on which a given class depends and has the following characteristics: Efferent Coupling determines the number of classes in other packages that the classes in a package depend upon.
• Efferent Coupling is an indicator of the package’s dependence on externalities.
• Outgoing dependencies : Efferent couplings signal outward.
• This has also been referred to by Robert C. Martin as the Fan-out stability metric which in his book Clean Architecture he describes as Outgoing dependencies. This metric identifies the number of classes inside this component that depend on classes outside the component.
• Efferent coupling is a coupling metric in software development, it measures the number of data types a class knows about.
• This includes inheritance, interface implementation, parameter types, variable types, and exceptions.
• This metric is often used to calculate instability of a component in software architecture
• I= Fan-out / (Fan-in + Fan-out).
• This metric has a range [0,1]. I = 0 is maximally stable while I = 1 is maximally unstable.
• Classes with high efferent coupling will receive the effects of changes or defects in other classes.
• A large efferent coupling can indicate that a class is unfocused and may also indicate that it is unstable since it depends on the stability of all the types to which it is coupled.
• Outgoing dependencies : Efferent (outgoing) couplings = Who do you depend on. Measure of how many different packages are used by a specific package.
• It is a code quality metric.

Instability Index :

• The instability index measures efferent coupling in relation to total coupling and is a code quality metric.
• The instability index measures efferent coupling in relation to total coupling: Instability Index = Ce / (Ca + Ce) Ce: Efferent Coupling Ca: Afferent Coupling This metric has a range [0,1]. A value of 1 means a code component is highly unstable, and a value of 0 means it is highly stable.

Lines of Code :

• Lines of Code is the number of lines in the text of the program’s source code with the following characteristics:
  • A high count might indicate that a type or method is doing too much work
  • A high count might also be a warning that code will be hard to maintain
• Lines of Code indicates the total number of executable lines of code in a method. This count is an approximate number, based on the Intermediate Language (IL) code.
• Lines of Code include only executable lines of code, so comments, braces, white space and member declarations are excluded.
• It isn’t a code quality metric
• Lines of Code is Code Metric which checks the Code Health.

Maintainability Index :

• Maintainability is directly related to technical debt il technical debt increases. then it will decrease maintainability of the product. So make sure that the maintainability quality attribute is adressed
• Maintainability Index measures how maintainable (easy to support and change) a source code is. It is an index value between 0 and 100. It is a code quality metric.
• Maintainability Index is Code Metric which checks the Code Health.

More informations for the Scrum PSD certification here.