Visustin calculates a few flow chart metrics. You can find this feature via the Statistics command in the View menu.
| Metric | Description |
|---|---|
| Lines | Number of physical source code lines the graph was created from. |
| Cyclomatic complexity | McCabe cyclomatic complexity number. |
| Decision density | Decision density = Cyclomatic complexity / lines of code |
| Links | Total number of links (graph edge count). All links are included, even those that do not look like an arrow. |
| Shapes | Total number of graph shapes (graph node count). There is an invisible shape at the start of a flow chart. |
Number of physical source code lines the graph was created from. This line count includes all lines, be it code, comment or blank. A line ends at a newline character. Line continuation characters are not taken into account.
Compatibility note: This metric equals the LINES metric of Project Analyzer.
The cyclomatic complexity metric measures the number of decisions in a program. Cyclomatic complexity is counted from the flow chart structure as follows:
Cyclomatic complexity = Number of decisions + 1
What are decisions? Decisions are caused by conditional and looping statements, such as if, select, switch, do, repeat, while, for or catch. In the flow chart, a decision looks like a decision diamond or a loop shape. A shape that has more than one outward link is a decision (unless it is a special case such as a call or GoSub jump).
When the code has no decisions, its cyclomatic complexity equals 1. There is no maximum value since code can have any number of decisions. – Cyclomatic complexity is also known as V(G), the graph theoretic number, or McCabe complexity.
Compatibility note: This metric equals the CC metric of Project Analyzer.
Visustin displays the cyclomatic complexity of any code you have selected. You can get the total complexity of an entire file (class, module, program). If you select a single procedure only, you get the complexity of that procedure.
Procedure cyclomatic complexity (CC) = Complexity of a single procedure
Total cyclomatic complexity (TCC) = Complexity of a class, module or program
Both types of complexity are calculated the same way: count the decisions, then add one.
A high cyclomatic complexity denotes a complex procedure that's hard to understand, test and maintain. There's a relationship between cyclomatic complexity and the "risk" in a procedure.
| CC | Type of procedure | Risk |
|---|---|---|
| 1-4 | A simple procedure | Low |
| 5-10 | A well structured and stable procedure | Low |
| 11-20 | A more complex procedure | Moderate |
| 21-50 | A complex procedure, alarming | High |
| >50 | An error-prone, extremely troublesome, untestable procedure | Very high |
The original, usual limit for a maximum acceptable value for cyclomatic complexity is 10. Other values, such as 15 or 20, have also been suggested. Regardless of the exact limit, if cyclomatic complexity exceeds 20, you should consider it alarming. Procedures with a high cyclomatic complexity should be simplified or split into several smaller procedures.
Cyclomatic complexity equals the minimum number of test cases you must execute to cover every possible execution path through your procedure. This is important information for testing. Carefully test procedures with the highest cyclomatic complexity values.
There is a frequently quoted table of "bad fix probability" values by cyclomatic complexity. This is the probability of an error accidentally inserted into a program while trying to fix a previous error.
| CC | Bad fix probability |
|---|---|
| 1-10 | 5% |
| 20-30 | 20% |
| >50 | 40% |
| approaching 100 | 60% |
As the complexity reaches high values, changes in the program are likely to produce new errors.
The use of multi-branch statements (such as switch, Select Case or Choose) often leads to high cyclomatic complexity values. This is a potential source of confusion. Should a long multiway selection be split into several procedures?
McCabe, the inventor of cyclomatic complexity, originally recommended exempting modules consisting of single multiway decision statements from the complexity limit.
Although a procedure consisting of a single multiway decision may require many tests, each test should be easy to construct and execute. Each decision branch can be understood and maintained in isolation, so the procedure is likely to be reliable and maintainable. Therefore, it is reasonable to exempt procedures consisting of a single multiway decision statement from a complexity limit. Note that if the branches of the decision statement contain complexity themselves, the rationale and thus the exemption does not automatically apply. However, if all the branches have very low complexity code in them, it may well apply.
Resolution: For each procedure, either limit cyclomatic complexity to 10 (or another sensible limit) or provide a written explanation of why the limit was exceeded.
Cyclomatic complexity is usually higher in longer procedures. How much decision is there actually, compared to lines of code? This is where you need decision density (also called cyclomatic density).
Decision density = Cyclomatic complexity / lines of code
Visustin saves metrics in .gif, .png and .tif images. You can view the metrics by loading the file back in Visustin and selecting Statistics. More about save formats
For a more thorough metrics analyzer, try Project Metrics in Project Analyzer. It works with Visual Basic, VB.NET and VBA and produces a wide range of complexity metrics and other measurements. Note that Project Analyzer and Visustin may produce different metric values due differences in the calculation technique.