To measure how a procedure receives, processes and passes data, we need metrics for its variables and parameters.
PARAMS = number of formal parameters in procedure header
The PARAMS metric counts the number of procedure parameters (arguments). The more parameters a procedure has, the harder it is to write a new call to it, and the more likely is an error to emerge when existing calls are changed.
A widely suggested maximum acceptable limit for PARAMS is 5. Other limits, such as 7, have also been suggested. The theory goes that humans can generally keep track of 7±2 chunks of information at once. Thus it they cannot keep track of more parameters either.
To reduce the number of required parameters, consider some of these solutions:
Since these solutions can have their own drawbacks, one should consider the benefits and drawbacks before changing the parameters.
VARSloc = Number of local variables and arrays defined in procedure
The VARSloc metric counts all local variables defined within a procedure. This means both procedure-level and block-level variables and arrays. VARSloc does not include procedure parameters.
The more variables there are in a procedure, the more complex its internal data processing seems to be. A very high VARSloc may indicate that the data processing is too complex and the procedure should be split up into smaller, more manageable pieces.
The following I/O metrics are related to the data input and output of a procedure. They measure the data flow into and out of individual procedures.
IOg equals the number of global and module-level variables accessed by a procedure. Each variable is counted only once regardless of the number of times the same variable is used in the code. An array is counted once regardless of the array elements accessed.
IOg = used variables (global and module-level)
When IOg=0, no external variables are accessed by the procedure. All data flows are via procedure calls: parameters and return values.
When IOg=0 and SFOUT=0, the procedure accesses no global variables and calls no other procedures either. It is an independent, self-contained procedure that is a candidate for reuse in other programs. Its functionality does depend on the parameters passed, though.
IOg does not include the following:
IOp equals the number of parameters used or returned by a procedure. The function return value counts as one parameter (output parameter).
IOp = used parameters + return value
IOp counts only the parameters that are actually used (or returned) by the procedure. Both input and output parameters are included. Unused parameters are not counted. The function return value is counted as one parameter if it is set. If it is not set, it is not counted.
A desirable IOp is between 0 and 6 (meaning max 5 parameters + return value, or 6 parameters and no return value). A higher IOp indicates too many parameters in the procedure.
When IOp=0, the procedure neither accesses nor returns any data via parameters or the return value.
IOvars measures the total number of input and output variables for each procedure.
IOvars = IOg + IOp
A high IOvars indicates a complex procedure what comes to data flow. You may want to split it up to reduce the complexity.
When IOvars=0, the procedure accesses no variable data. It can call other procedures that do access data, though. It may access constants. It may also access a database, a disk file, a device or some other form of external data.
When IOvars=0 and SFOUT=0, the procedure accesses no variable data and calls no other procedures either. It is an independent, self-contained procedure that is a candidate for reuse in other programs.
IOp and IOg are used to count IOg% Global I/O ratio, which measures the use of global/module-level variables versus parameters.