Metrics Narration
Metrics Definitions
Source Code Size Metrics
LOC – Lines of Code Metric
The LOC metric is generated by the default operation of RSM and by the –s runtime option.
RSM accounts for all the work performed in the development process and presents information in a variety of ways to comply with any LOC measurement style. These metrics include Lines of Code (LOC), comment lines, blank lines, lines of a single brace or parenthesis, effective Lines of Code (eLOC), code statements, and both logical and physical lines in the source file.
LOC - A common basis of estimate on a software project is the LOC or Lines of Code. LOC are used to create time and cost estimates. The LOC estimate becomes the baseline to measure the degree of work performed on a project. Once a project is underway, the LOC becomes a tracking tool to measure the degree of progress on a module or project. An experienced developer can gage a LOC estimate based upon knowledge of past productivity on projects. The LOC measurement becomes the barometer for the program’s progress and productivity.
A standard definition and measurement technique for lines of source code is required to create a uniform basis of estimate for software projects. This measurement method must be independent of the operating system and applied uniformly to form a sound basis of estimate. Projects within a company will often use different methods for counting lines of code because a portable tool is not available for use on all operating systems, until the development of Resource Standard Metrics.
How is LOC determined by RSM? - A good metrics tool, such as RSM, must account for all metrics in the source file. Many tools hide their LOC determinations from the user, giving doubt to the validity of the measurement. RSM in deterministic mode (-d) will show the user the LOC determination for every line in the source file.
eLOC – Effective Lines of Code Metric
The eLOC metric is generated by the default operation of RSM and by the –s runtime option.
eLOC - An effective line of code or eLOC is the measurement of all lines that are not comments, blanks or standalone braces or parenthesis. This metric more closely represents the quantity of work performed. RSM introduces eLOC as a metrics standard.
Many programmers use a single brace or parenthesis on a line to block scope or code. This practice is very common, creates very readable code and is mandated by many commercial companies coding practices. A single character on a physical line may not create a line of code which is representative of actual work performed by the programmer. This type of coding style will inflate LOC metrics by 20 to 40 percent.
RSM counts the instances of lines that contain a single brace and parenthesis and creates a metric for effective lines of source code, eLOC. This metric is the result of subtracting the single braces and parenthesis from the LOC measurement.
lLOC - Logical Lines of Code
Logical lines of code represent a metrics for those line of code which form code statements. These statements are terminated with a semi-colon. The control line for the "for" loop contain two semi-colons but accounts for only one semi colon.
LOC Example
Source code line LOC eLOC lLOC Comment Blank
--------------------------------------------------------------
if (x<10) // test range x x x
{ x
// update y coordinate x
x
y = x + 1; x x x
} x
--------------------------------------------------------------
Code Statement Metric
The code statement metric is generated using the –v runtime option.
Traditional source code size metrics are determined by counting the code statements. A code statement is defined as a line of code that is terminated in a semi-colon except in the case of a "for" statement. "For" statements form a singular statement even though they contain two semi-colons. The code statement metric is typically 30 to 50 percent of the eLOC metric. Therefore this assessment or estimation metric may not accurately reflect the quantity of work to be performed.
File Count Metric
The file count metric is automatically generated when more than one file is processed.
RSM counts the files processed and generates metrics based on the file extension. This metric will provide the distribution of the source code types, source code types and distribution of the specifications to the implementations (*.h* to *.c* ).
Source Code Understandability Metrics
Understandability metrics are generated with the –v runtime option.
Comment Line and Comment Percent Metric
RSM counts each comment line. The degree of commenting within the source code measures the care taken by the programmer to make the source code and algorithms understandable. Poorly commented code makes the maintenance phase of the software life cycle an extremely expensive adventure.
Comments can occur by themselves on a physical line or be co-mingled with source code. RSM counts a comment line as any physical line that contains a comment. You will notice the sum of the lines of code, comments and blank lines often exceeds the physical line count. This is expected a when comments are co-mingled with source code. This summation is known as the logical line count.
Comment Percent = Comment Line Count / Logical Line Count ) x 100
Logical Line Count = LOC + Comment Lines + Blank Lines
Blank Line and White Space Percent Metric
The number of blank lines within source code determines the readability of the product. White space accents the logical grouping of constructs and variables. Programs which use few blank lines are difficult to read and more expensive to maintain.
RSM counts the spaces and characters within the source code. The white space percentage metric is another measure of readability for the source product.
White Space Percentage = (Number of spaces / Number of spaces and characters) * 100
Function Metrics
Function metrics are generated with the –f runtime option.
Function Count Metric
The total number of functions within your source code determines the degree of modularity of the system. This metric is used to quantify the average number of LOC per function, maximum LOC per function and the minimum LOC per function.
Average LOC per Function Metric
The average LOC per function indicates how the code meets the accepted standard. An accepted industry standard of 200 LOC per function is desired as the average LOC per function. Functions that have a larger number of lines of code per function are difficult to comprehend and maintain. They are a good indicator that the function could be broken into sub functions whereby supporting the design concept that a function should perform a singular discrete action.
Maximum LOC per Function Metric
Although the average LOC per function can yield an interesting source code trend, the maximum LOC per function will provide a definitive metrics on the largest function in the system.
Minimum LOC per Function Metric
A minimum LOC per function of 2 or less can indicate functions that may have been prototype but not yet complete. This insight can be valuable in assessing the existence of functions that may have been automatically generated by a CASE tool but not implemented by the programming team.
Cyclomatic Complexity
Cyclomatic complexity is the degree of logical branching within a function. Logical branching occurs when a "while", "for", "if", "case" and "goto" keywords appear within the function. Cyclomatic complexity is the count of these constructs. Some software engineers do not recognize the "for" repetition as a logical branching structure, as such, RSM provides the capability to remove this count from the cyclomatic complexity.
Presentation of Cyclomatic Complexity
Function Interface ComplexityThe function interface complexity is created using the –c runtime option.
Interface complexity is comprised of the number of function parameters and the number of function return points. Functions with greater than 6 input parameters can be very difficult to use on a routine basis and are problematic to parameter ordering. Functions with greater than one return point break the single entry/single exit design constraint. Functions of this type are difficult to debug when a runtime error occurs. RSM provides quality notices for functions with a high number of input parameters and for the occurrence of more than the specified number of return points.
Functional interface complexity is used to generate the average, maximum and minimums per function. These trend indicators are also created for the functional parameter metric and return point metric.
Function Parameter Metric
The function parameter complexity metric provides insight to the complexity of the function’s interface. Functions with a large number of input parameters are difficult to use and are subject to parameter ordering errors. These types of functions are generally not well designed and should be examined for the design constraint for a function to perform a single purpose.
Function Return Point Metric
Multiple function return points are very problematic for tracing error conditions with a set of source code. Ideally a function should be a black box with a single entry point and a single exit point. Multiple exit points are easy to program but they increase maintenance costs and propagate what is called "Spaghetti" logic. Programmers should be urged to add the additional logic structure to create single return point functions.
Macro Metrics
Macro metrics are generated by the –m and –v runtime options.
Macro Count Metric
The number of macros used in a system indicates the design style used to construct the system. Systems heavily laden with macros are subject to portability problems. The compiler pre-processor is responsible for the expansion of macros within the source code. As there is no standard for macro syntax as there is for the ANSI source code languages, the expansion order of the macro can change from compiler to compiler, thus yielding different numerical results. We have observed the pre-increment operator (++) yielding different numerical results between two different compilers on the same operating system.Macro syntax is greatly different than the syntax of the source code language. Macro will make your less understandable and difficult to maintain. As macros are expanded prior to the compilation step, most debuggers will only see the macro name and have no context as to the contents of the macro, therefore if the macro is the source of a bug in the system, the debugger will never catch it. This condition can waste many hours of labor. RSM provides a quality notice for the user of the use of the pre-increment operator within a macro.
Macro LOC Metric
The macro LOC metric yields insight into how large macros are in the system. The larger the macro, the more complex it’s structure and the greater the probability for erroneous behavior to be hidden by the macro.
Class Metrics
Class metrics are generated with the –o and –v runtime option.
Class Count Metric
The number of classes in a system indicates the degree of object orientation of the system. RSM uses this metric to determine the average lines of code per class, maximum LOC per class and minimum LOC per class.
Average LOC per Class Metric
The average LOC per class can provide insight into the average module size in the system. Systems that are comprised of extremely large modules can be indicative of loosely cohesive modules. These types of modules are bloated in size because functions are added that are not dedicated to the initial purpose of the module.
Maximum LOC per Class Metric
The maximum LOC per class will provide the measure of how large the largest module has become. When a class exceeds 1000 LOC, it deserves a review to determine whether the class is still a cohesive module.
Minimum LOC per Class MetricClasses with this metric equal to 1 are a good indication that there are classes that were conceived by the development team but never implemented.
Language Keyword MetricsRSM records counts for specific keywords used with the source code.
These metrics are generated while using the –v runtime option. The interpretation of such metrics varies widely between RSM users, but most often these metrics give insight into the code content without have to read to source code.
The following RSM extract provides an example of the –v output which yields the Keyword Metrics.
~~ Project Keywords and Metrics ~~
--------------- LOC --------------- case, break .........: 4, 4
Lines of Code (LOC) .: 1312 if, else ............: 34, 10
Lines of just { or } : 372 goto, return ........: 0, 47
Lines of just ( or ) : 0 exit, _exit, abort ..: 0, 0, 0
Effective LOC (eLOC) : 940 macros, struct, union: 0, 0, 0
Code Statement (lLOC): 498 class, interface ....: 8, 0
-------------- Lines -------------- template, friend ....: 0, 0
Blank Lines .........: 293 namespace, package ..: 1, 0
Comment Lines .......: 118 inline ..............: 3
Total Logical Lines .: 1723 Memory alloc, free ..: 0, 0
Total Physical Lines : 1700 Memory new, delete ..: 4, 3
------------ Key Words ------------ ------------- Analysis ------------
Literal Strings .....: 150 Continuation Lines \.: 0
Preprocessor Lines #.: 126 Paren Count (,) .....: 431, 431
#include, import ....: 45, 0 Brace Count {,} .....: 199, 199
#define, typedef ....: 8, 0 Bracket Count [,] ...: 79, 79
const, enum .........: 28, 6 Chars/NBLine, Notices: 15, 35
do, while ...........: 1, 4 Code, eCode Lines ...: 76.1%, 54.6%
switch, default .....: 1, 1 Comment, Blank Lines : 6.8%, 17.0%
for .................: 16 Characters, Spaces ..: 77.6%, 22.4%
One can quickly gauge the content of the source code. Ten dependencies are represented by the "# include" metric. There are three "# defines"
which probably should be converted to constants. There are three "for loops" used for repetition and a few "if/else" constructs.
The verbose report can provide virtually an unlimited number of ways to interpret the source code. It is one of the most popular reports to run from Resource Standard Metrics. When the –n runtime option is used to perform a quality analysis of the source code the total number of notices is shown on this report. Many users examine this value and when it is equal to zero, the code is ready for formal review.
File MetricsThe verbose report and many of the other RSM reports are created and summarized at the file level. All functional and class metrics are rolled up into a file summary.
Project MetricsEach file summary is rolled up into a project summary. RSM performs streaming technology where as a file is encountered for processing, its metrics are recorded and streamed to the output device. This provides both the detail and summary of all metrics. If you page to the end of the metrics report you will see the project indicator indicating the total number of files processed.
© 2013, M Squared Technologies LLC™