Software metrics are used to look at software quality as the conformance of a software product to some pre-defined set of functional requirements at a specified level of quality. Limitations however, make these metrics impractical and incapable of measuring salient software characteristics. Most of this impracticality arises from the point in the software development process at which the metric may be applied. Code metrics are essentially irrelevant in the software requirements and design phases. In order to evaluate the usefulness of a software quality metric, we need to examine its usefulness in:

• Setting goals.
• Measuring progress.
• Evaluating whether the goals have been met.

Cyclomatic complexity is used to evaluate the complexity of an algorithm in a method. Cyclomatic complexity of a function is defined as the number of independent paths that a program can take during execution of that function. This also provides the number of test cases that are needed to test the method comprehensively. When represented as a connected control-flow graph, a program can use measurements based on that graph to obtain a cyclomatic complexity measure. To produce the control-flow graph, processes are represented by nodes, and these are connected by edges with arrows pointing in the direction of program flow. A list of sequential processes are usually grouped as one process. Form the graph, the following measurements are made:

• E = number of edges
• n = number of nodes
• p = number of connected components (normally the value 1 is used)

From this information, cyclomatic complexity is defined as:

• V(G) = E - n + 2p

For a sequence where there is only one path, no choices or no option, only one test case is needed. A construct like an IF loop however, has two choices; if the condition is true, one path is tested; if the condition is false, an alternative path is tested.

A method with a low cyclomatic complexity is generally better than a method with a high complexity. A low complexity may imply testing is decreased and understandability is increased, or that decisions are deferred more through message passing, not that the method is necessarily more simple. It is also important to note that the complexity level is not necessarily related to the number of lines of code in a function. Large functions can have low complexity, and small functions can have large complexity levels.

There are many good reasons to limit cyclomatic complexity. Overly complex modules are more prone to error, harder to understand, harder to test, and harder to modify. Deliberately limiting complexity at all stages of software development helps avoid the pitfalls associated with high complexity software.

The size of a program module as measured by number of lines of code is perhaps one of the simplest (and definitely one of the first) metrics that can be used to evaluate the quality of a program. As the size of the program increases, their will be more lines of code contained within the program or program module. As the number of lines of code increases, so does the overall complexity of the program module. As a result of increasing number of lines of code, the module will be more prone to errors as the size of the program increases.

One of the major problems with the lines of code metric is that there is no standard as to which lines should be included in a count. Described here is an example of one of the many sets of guidelines used when counting lines. What must be counted is the number of language statements, or logical lines of code. Many actual physical lines in the source code file may not contain language statements. These include blank lines and comment lines.

A Standard for counting C code could count each instance of the following as one line of code:

• Each brace, closing and opening.
• Each executable line.
• Each declaration of a variable or function, including a function header.
• Each for (loop), if (condition), do, return (value), or while (condition).
• Each instance of a compiler directive.

Comments and blank lines are not counted.

Cyclomatic complexity can be very useful in the domain of real time programming. Because this type of program needs to execute in a given time frame, maintaining a certain level of complexity becomes of utmost importance. This metric can be used to set a goal to remain within a particular complexity level. If the response time of certain complexity levels can be discovered, then functions can be designed that stay within these time restrictions. By reporting on these results, it can be ensured that the system will operate in the time required, thus ensuring that those goals have been met.

Cyclomatic complexity alone in an object-oriented domain is not so useful. This metric cannot be used to measure the complexity of an object-oriented class because of inheritance. However, the cyclomatic complexity of individual methods can be combined with other measures to evaluate the complexity of the class.

A real time application would benefit from the measurement of the number of lines of code. Real time systems must respond to real world events within a specific time frame. The number of lines of code that must be executed in response to an interrupt event is significant if the real time system is going to respond within the specified time frame. To ensure that program modules do not exceed a certain degree of complexity, it would be beneficial to establish a maximum number of lines per module. It could be easily confirmed that the goal of simplicity was then being met.

An object-oriented program would not benefit from the use of the Number of Lines metric. Being an older metric, it is more applicable to older domains (non-object oriented). In the past, this metric has been used to measure the amount done on a project in a given time frame. For example, it was used to analyze the number of lines of code generated by a programmer in a month’s time. This was used to set milestone and completion goals. Because of the reusability of object oriented code, this would no longer be applicable. By reusing code, a programmer could accomplish much in a given time frame with only a small amount of written code.

Pressman, Rodger. "A Practitioners Approach to Software Engineering,". Mcgraw Hill, 1997.

Sommerville, Ian. "Software Engineering, 6^th Edition". Addison Wesley, 2001.

Kolewe, R. Metrics in Object-Oriented Design and Programming. Contents copyright © 2000 Eridani Inc.