Project Metrics allows you to define threshold values for each metric. You can find this feature in the Options menu. You can define a set of rules, one rule per each metric you're interested in. Define an acceptable range or a minimum/maximum acceptable value. Alternatively, you can watch out for outliers, which are exceptional values in the data at hand.
| Limit type | Acceptable range | Warning range |
|---|---|---|
| <= "Must not exceed" | metric <= limit | metric > limit |
| Range | lowerlimit <= metric <= upperlimit | metric < lowerlimit metric > upperlimit |
| >= "Must be at least" | metric >= limit | metric < limit |
| Outliers | "Normal" values | Exceptionally low or high values |
| Extreme outliers | "Normal" values | Extremely exceptional low or high values |
If the metric exceeds its limits, it is displayed in red to catch your attention.
You can define several sets of limits. For example, you could define easy limits for a quick quality check and stricter limits to achieve gold quality. Alternatively, you can use different limits for different kinds of projects if you feel that's the correct approach in your work.
Notice that rounding may give some effects at the boundaries. For example, if your limit is <=4, the value of 4.0 may be shown in red if it the exact value is 4.02.
Project Metrics supports a number of predefined rule sets for quick access. You can use them as a starting point for defining your own limits.
| <Default limits> | Suggested set of basic limits, see below. |
|---|---|
| <No limits> | No rules apply, metrics can have any value. |
| <Outliers, extreme> | Statistically extremely exceptional values are detected. |
| <Outliers> | Statistically exceptional values are detected. |
| <Require comments> | The amount of commentation and whitespace should be reasonable for the project and each individual file as well. Each procedure should be commented. |
This set of rules is a suggestion for a basic set of limits. You can change the limits according to your standards, add values you want to monitor and remove metrics that you're not interested in. The limits are fully configurable. It is not compulsory to follow the default limits, these are only a starting point.
| Limit | Explanation |
|---|---|
| maxDIT <= 5 | Class inheritance tree should be limited to a reasonable depth. |
| AHF >= 1 | Class variables should always be declared private (AHF=1). This is the same as VARSnp but on the project level. |
| File LLOC >= 1 | File should not be empty. |
| Class LLOC >= 3 | Class should not be empty. |
| Class DIT <= 5 | Class inheritance tree should be limited to a reasonable depth. |
| WMC in range [1,50] | Class should define at least one method and the number of methods should be reasonable. |
| VARSnp <= 0 | Class variables should always be declared private (VARSnp=0). This is the same as AHF but on the class level. |
| LCOM1 <= 0 | LCOM1 other than 0 indicates class that lacks cohesion. |
| LCOM3 <= 0.99 | LCOM3 >= 1 indicates class that lacks cohesion. |
| LCOM4 <= 1 | LCOM4 >= 2 indicates class that lacks cohesion. |
| Procedure LINES <= 66 | Procedure should fit on one page when printed. |
| Procedure LLOC >= 3 | Procedure should have executable content. |
| Procedure MCOMM >= 1 | Procedure should be commented. |
| CC <= 10 | Cyclomatic complexity should be limited to a reasonable value. |
| DCOND <= 5 | Conditional nesting should be limited to a reasonable depth. |
| DLOOP <= 2 | Loop nesting should be limited to a reasonable depth. |
| PARAMS <= 5 | Number of procedure parameters should be limited. |
Below you can find suggested limits that are not on by default. You can add them by yourself if you feel they could be useful with your projects.
| Limit | Explanation |
|---|---|
| ROOTS <= 1 | The class hierarchy should derive from a common root class. This rule is not applicable to VB Classic where inheritance doesn't exist. |
| DEAD <= 0.05 | Amount of dead code should not exceed 5%. |
| Project LLOW% in range [0.08,0.20] | A reasonable amount of empty lines should be used to add legibility to code. This rule requires that 8%..20% of lines are empty. Other ranges, such as 8%..16%, 10%..20% and 10%..30% have a also been suggested. |
| File LLOW% in range [0.08,0.30] | A reasonable amount of empty lines should be used to add legibility to code. This rule requires that 8%..30% of lines are empty in each file. We allow up to 30% for a file to reduce false warnings. Notice that there are special cases such as very short files, skeleton files and classic VB abstract .cls files that may have a high LLOW% without it being a problem. |
| Project MCOMM% >= 0.2 | Code should be well commented. 0.2 = 20% means one meaningful comment for every 5 code lines. |
| File MCOMM% >= 0.15 | Files should be well commented. 0.15 = 15% means one meaningful comment for every 7 code lines. You can use a lower MCOMM% for files than the complete project. This allows for variation. Some files are more complex and need more comments, while other files need less. |
| Project LENV in range [9,16] | Variable names should be descriptive. This rule requires the average length to be between 9 and 16 characters. |
| File LINES in range [5,1000] | The number of lines in a file should be reasonable. Very short files are probably not necessary. Extremely large files should be split to make them easier to understand. |
| File PROCS <= 50 | The number of procedures in a file should be limited to a reasonable value. The actual maximum limit is up to your consideration. |
| File VARS <= 50 | The number of variables in a file should be limited to a reasonable value. The actual maximum limit is up to your consideration. |
| File CONSTS <= 50 | The number of constants in a file should be limited to a reasonable value. If a large number of constants is required, enums are an alternative way to group related constants together. Instead of a large number of string constants, consider the use of a resource file. |
| Class VARSi >= 1 | Class should either define or inherit some variables. Stateless classes should be rewritten as modules. |
| Class VARS <= 7 | Class with more than about 7 variables is a candidate for splitting into several classes. |
| Class CTORS >= 1 | Class should explicitly define one or more constuctors. This rule is not applicable to VB Classic where constructors don't exist. |
| Class CIS <= 20 | Class interface size, the ways a class lets others access its methods and data, should be limited. This limit could also be written as WMCnp <= 20 if VARSnp=0. |
| Class CBO <= 14 | Class should not be excessively coupled to other classes. |
| Procedure VARS <= 10 | A large number of local variables indicates a complex procedure that should potentially be split. |
| Procedure LENP >= 5 | Procedure should have a descriptive name. |
| Procedure SFOUT <= 10 | A large structural fan-out indicates a complex procedure that should potentially be split. |
Outliers and extreme outliers are exceptional values in the data at hand. By using either the Outliers or Extreme outliers limits you watch out for exceptional values without defining numerical ranges. Outliers and extreme outliers are the exceptionally low and high values in a metric series. They are calculated statistically.
You can quickly apply outlier limits by selecting either <Outliers> or <Outliers, extreme> as the limit set.
Fixed values are just one approach to setting the limits. Another way is to use the project itself as a basis. This is somewhat similar to using the outliers. In this approach, you compare the files to other files in the project (and similarly, classes to classes and procedures to procedures). You're interested in finding the outliers to focus your coding efforts on those parts of the code that seem to differ from the others in terms of complexity, size or any other metric. You define an acceptable range for each metric with the following formula.
Acceptable range = [Average - 3*StdDev, Average + 3*StdDev]
Anything that is not in the acceptable range is a potential quality problem. You can find the average and standard deviation (StdDev) values below the metrics grid. Use these values to define the limits for each project.
Caution should be exercised with this approach. If the overall quality of the project is poor, the acceptable range may become too wide.
Readings