Project-level metrics

Project Metrics

Project-level metrics are high-level measurements. They are counted for the entire analyzed project, group of projects or solution.

Even though the name would imply otherwise, project-level metrics are not counted for each individual project in a project group or solution. If you require project-level metrics for individual projects in a project group/solution, analyze each project separately.

Simple project-level metrics

FILES	Number of files	All files in project, including source files, binary property files, resource files and referenced files.
PROCS	Number of procedures	Subs, functions, property blocks, API declarations and event declarations found in source code.
VARS, VARSgm, VARSloc	Number of variables	See description below.
CONSTS	Number of constants	All constants defined in source. Excludes enum constants and compiler constants (#Const).
UDTS	Number of user-defined types	All Types and Structures defined in source files.
ENUMS	Number of Enums	Enums defined in source.
ENUMCS	Number of Enum constants	Enum constant names defined in source.
FORMS	Number of forms	Number of standard Windows forms. Usercontrols, property pages, web forms etc. are not counted.
MDLS	Number of standard modules	Number of standard modules: .bas files and Module blocks.
DATE	Project date	Date of newest file in project.
DATEF	Average file date	Average file date in project. Not available for exported VBA projects.
kB	Project size	The total size of all source code files in kilobytes. External files, such as DLLs and COM files are not included.

Dead code metrics

The dead code metrics measure the amount of dead or inoperative code in the source. Deadness is defined on the Terminology page.

dPROCS	Number of dead procedures	Counts all dead procedures and "dead but exposed" procedures. Includes procedures whose callers are dead. Compare to PROCS.
dVARS	Number of dead variables	Counts all dead and semi-dead variables and parameters. Includes written-only and read-only variables. Does not include variables whose readers and/or writers are dead. Compare to VARS.
dCONSTS	Number of dead constants	Counts all dead constants. Does not include constants whose users are dead. Compare to CONSTS.
dUDTS	Number of dead user-defined types	Counts all dead UDTs. Does not include UDTs whose users are dead. Compare to UDTS.
dENUMS	Number of dead Enums constants	Counts all dead Enums constants. Does not include Enum constants whose users are dead. Compare to ENUMCS.
dENUMCS	Number of dead Enums	Counts all dead Enums. Does not include Enums whose users are dead. Compare to ENUMS.
dLINES	Dead lines	Physical lines in dead procedures. This metric represents the amount of code that could be eliminated via dead procedure removal. Other removable lines are not included: no dead classes, no dead variables, no dead enums, no dead consts and so on.
DEAD	Deadness index	The average percentage of dead code. DEAD = (dPROCS + dVARS + dCONSTS) / (PROCS + VARS + CONSTS)

Note: dVARS does not include used variables whose writers, readers or both are dead. Similarly, dCONSTS does not include used constants whose users are dead. Even though these variables and constants are effectively dead, dVARS and dCONSTS do not include them to keep dVARS and dCONSTS values comparable across Project Analyzer versions 8.0 and later.

Enum metrics

ENUMSZ Average Enum size

This metric counts the average number of constants in an Enum block. We get it by simply dividing the number of individual constants by the number of Enums.

ENUMSZ = ENUMCS / ENUMS

At a minimum, an Enum consists of a single constant. Thus, the minimum value of ENUMSZ is 1 when there is at least one Enum in the project. When there are no Enums, ENUMSZ=0.

A low ENUMSZ indicates a project with (many) small Enums. A large ENUMSZ indicates a project with big Enums.

ENUMR Enum ratio

Enum ratio is the percentage of Enum constants among all constants. It measures the relative "enumeratedness" of constants, or the relative use of Enums versus Consts.

ENUMR = ENUMCS / (ENUMCS+CONSTS)

ENUMR varies from 0% to 100%. At 0%, there are no Enums. At 100%, there are only Enums.

The more Enum constants there are relative to regular constants, the higher ENUMR. A high ENUMR is usually a good thing. Related integer constants should be defined as Enums when possible. Using Enums instead of regular constants makes code more self-describing.

Enums are especially descriptive and useful as data types of parameters and function return values. With an Enum parameter it is immediately clear which values are acceptable for the parameter. With a regular constant the developer has to read the documentation to understand which constant values may be passed in which parameter.

Enum constants are only available for integers. Since programs frequently require decimal and string constants, it is not usually possible to achieve an ENUMR of 100%.

Procedure call metrics

These metrics deal with the total and relative number of procedure call statements.

CALLS	Number of procedure calls	Number of procedure call statements, including calls to subs, functions and declares, accesses to properties and the raising of events. Implicit calls (such as Form_Load) are not counted.
CALLDENS	Call density	Average number of calls on a code line. Measures the modularity or structuredness. CALLDENS = CALLS/LLOC

Reuse metrics

RB Reuse benefit (of procedures)

Reuse benefit RB is the extent to which you reuse your procedures. A procedure that is being called at several locations is said to be reused. A procedure that is called just once or not at all is not reused. RB measures the overall amount of reuse in the entire system.

Reuse benefit for a program is calculated as follows.

RB = (Size − ΣSTMT) / Size

Size = Σ(STMT * Usage)

Usage = Max(SFIN, 1)

STMT is the number of statements in a procedure.
ΣSTMT is total number of statements in all procedures.
SFIN is the structural fan-in of a procedure (the number of callers).
Usage of a procedure equals the number of callers (SFIN), but the minimum Usage is 1. Thus, we assume that each procedure is called at least once. This covers dead procedures and "automatically called procedures" such as event handlers.
Size of a program is the sum of statements times Usage for each procedure. The more reuse, the higher Usage, and the larger Size.

0 <= RB < 1. RB=0 indicates no reuse. A very high amount of reuse causes RB to approach 1, but it will never reach 1.

Reuse benefit is correlated with productivity and error density. The more you reuse, the more productivity you gain and the less errors your code is likely to contain. Thus, higher RB values are an indication of better coding.

Theoretical examples:

If there is no reuse, Usage=1 for every procedure. Size = Σ(1 * STMT) = ΣSTMT. Thus, RB = (1−1)/1 = 0.
If all procedures are reused once, they have two callers. Usage=2 for every procedure. Size = 2 * ΣSTMT. Thus, RB = (2−1)/2 = 0.50.
If all procedures are reused twice, they have three callers. Usage=3 for every procedure. Size = 3 * ΣSTMT. Thus, RB = (3−1)/3 = 0.67.

RB readings

Reuse benefit has been defined by Devanbu and Karstu in 1994.

Devanbu et al: Analytical and Empirical Evaluation of Software Reuse Metrics. IEEE 18th International Conference on Software Engineering (1996) p. 186-.

Rc Reuse of constants

Rc measures the reuse of constants and enum constants. When you refer to a constant in your code, you use it. When you use it the 2nd, 3rd etc. time, you reuse it. Rc measures the average number of times you reuse your constants.

Rc = uses / count − 1

uses = number of references to constants and enum constants

count = number of all used constants and enum constants

If count = 0, Rc is undefined.

Rc is equal to the average number of "extra" references to constants and enum constants.

A high Rc indicates that the constants defined are meaningful and widely used. The higher Rc, the more reuse. When Rc=1, the average constant is used twice (reused once). When Rc=2, each constant is used three times (reused twice), etc.

The minimum Rc is zero. In this case there is no constant reuse. No constant is referenced more than once. A low Rc is not necessarily problematic, but it may indicate improper use of constants:

If the constants are defined several times, the average amount of reuse stays low. This happens when local constants are used in each procedure, for example. Use the Constant analysis feature of Project Analyzer to determine whether this is the case.
If literal values are used instead of defined constants, Rc stays low.

Dead constants have no effect on Rc.

Project-level variable metrics

These variable metrics sum up values of individual variables. See Variable metrics for description.

VARS	Number of variables	All variables, arrays and parameters defined in source, whether global, module-level or local.
VARSgm	Global and module-level variables	VARSgm counts global and module-level variables — all variables and arrays that are not procedure local variables or parameters. The variable may be declared in a module, class or .NET Structure, but always outside of procedures.
VARSloc	Local variables	Total number of procedure local variables and arrays, excluding parameters. Sums up VARSloc for each individual procedure.
TREADS	Total variable reads	TREADS counts the number of read instructions from global and module-level variables. TREADS=Sum(READS)
TWRITES	Total variable writes	TWRITES counts the number of write instructions to global and module-level variables. TWRITES=Sum(WRITES)
TRW	Total variable reads+writes	TRW sums TREADS and TWRITES. See RW for discussion. TRW=TREADS+TWRITES

DATADENS Data access density

DATADENS = TRW / LLOC

Data access density measures the average number of variable access instructions per a logical line of code. By variable access we mean read or write access to global and module-level variables.

A high DATADENS indicates a data intensive program that uses direct variable access instead of passing data via parameters and properties. A low DATADENS indicates a program that either uses a limited amount of data or that passes data via parameters and properties.

A very high DATADENS is not desirable. You can make it lower by encapsulating data as properties and passing it as parameters. A high DATADENS is especially undesirable if it occurs because of direct variable access across modules. It can be more tolerable if the majority of variable access happens within modules. This is the case if you can define variables as Private or Protected rather than Public or Friend.

IOg% Global I/O ratio

Global I/O ratio (or global data use) measures the amount of data flow due to the use of global and module-level variables versus the use of procedure parameters and function return values. It is counted for the entire system by summing up the global and parameter I/O values for each procedure.

IOg% = Sum(IOg) / Sum(IOg + IOp)

When IOg% = 0%, all data is passed via parameters and function return values. This scenario may be desired in some designs.

When IOg% = 100%, all data is being accessed via global and module-level variables. This scenario is undesirable.

See Procedure data I/O for discussion and definitions of IOg and IOp.

Project Metrics