Project-level 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.


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 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)

0 <= RB < 1. RB=0 indicates no reuse. A very high amount of reuse causes RB to approach 1, but it will not 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:

RB readings

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

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:

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.
TWRITES Total variable writes TWRITES counts the number of write instructions to global and module-level variables.
TRW Total variable reads+writes TRW sums TREADS and TWRITES. See RW for discussion.

DATADENS Data access density


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 accross 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.

©Aivosto Oy - Project Analyzer Help Contents