These reports are available in the Report menu.
This report summarizes the use of compiler directives in the project. Compiler directives are #If, #ElseIf, #Else, #End If, #Const, #Region and any other lines starting with #.
The report includes a section on how conditional compilation affects your project. It shows how many lines are included in #If..#End If blocks. It also shows how many of those lines are excluded from compilation and how many are included, thus being active lines in the compiled executable.
Compiler constants are listed at the end of the report. This section includes #Const definitions, your project-level settings (conditional compilation arguments) and built-in compiler constants.
Sample report: Compiler directives report
This report lists all run-time libraries used by the project. Run-time libraries usually have one of the following extensions: .dll, .tlb, .ocx or .vbx
The report starts with a listing of libraries and their versions as installed on the system where Project Analyzer is run. The report includes the files you have checked in the References and Controls dialog boxes (VB 4.0 and later) and the files mentioned in any Declare statements or <DLLImport> procedures.
After that, all DLL procedure declarations are listed. If they are not used, they are marked as "dead". Note that this deadness applies to the declarations, not to the target DLL procedures. A DLL procedure may be declared several times in several modules, possibly with different alias names and parameter types. A dead declaration does not necessarily mean that the target procedure in the DLL is dead.
The report includes a list of duplicated DLL declares. You can use it for finding the same procedure declared in several ways or at several locations.
There is also a section listing library base addresses. This is useful for library projects. Each library should have an individual base address to avoid relocation when Windows loads the library in memory. Having the same base address for several libraries means Windows will have to relocate the internal addresses in the file before the code can execute, which adds to load time.
Sample report: Library report
The Design quality report gives an overall picture of the quality of a project.
The report includes a large number of different metrics. You learn about the size of source files and the length and complexity of procedures. The report includes a section on cyclomatic complexity, which is a widely used method for finding error-prone procedures. The report also measures internal reuse, understandability and object-orientedness. There is a section on the programming problems found. Furthermore, the report shows the distribution of line lengths and includes information on whitespace, indentation and tab stops.
A Quality assessment section gives a general idea of the quality of the code being analyzed. Quality levels vary from 0 to 10. The Quality assessment section is an attempt to distill "good" vs. "bad" code into a few numbers. Do not take the results too seriously. Use the information for comparing projects or for tracking positive vs. negative development. The qualities considered are syntactical qualities. The quality levels do not tell you if your code performs correctly and does the right thing.
Note: The Naming section analyzes most names in the project. It ignores names whose definition depends on other declarations. The idea is that a developer has not named them independently and therefore they shouldn't be considered when evaluating naming quality. Ignored names: see metric LEN. On the contrary, the Dictionary considers all names, giving a bit different statistics.
Sample report: Design quality report
The Summary report summarizes the size and status of the system analyzed. You can use the Summary report as a statistical information source during various stages of your project.
The report summarizes the size of your system in many different ways. The report includes line counts, number of active lines, number of lines excluded by conditional compilation, number of generated lines, and lines classified into lines of code, lines of comment, lines of whitespace, number of statements and kilobytes of source. You even get a work effort estimate in man-months. The work effort estimate should be taken with grain of salt, though. It's based on the assumption that a developer writes 100 lines per day, not taking project complexity or programmer productivity into account.
Besides evaluating the project size, the counts the number of files, modules, procedures, variables, parameters, constants, Enums, line labels and other definitions. You get to see the number of sub-procedures, functions, properties, events and the like. You also get counts by scope, such as global and module-level or Public and Private.
In addition to size metrics, the report includes a section counting the number of key VB statements such as If, Else, For, Do and the like. You get to see the number of branching statements, looping statements, jump statements and error handling statements. You also get the number of branches and loops in the analyzed system. What is more, the report shows the total number of statements classified into control statements, non-control statements, executable statements and declarative statements.
A section on decisions shows how many decision points exist in the analyzed system. The section classifies decision points by statement type such as If, ElseIf, Case, Do While, Do Until and the like. What is more, the Summary report also shows the number of key operators such as Not, And and Or.
Sample report: Summary report
Tip: To learn more about the metrics in the Design quality and Summary reports, read the Project Metrics section of this help.