These reports are available in the Report menu.
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 source file sizes, procedure lengths and complexity metrics. The report includes a section on cyclomatic complexity, which is a widely used method for finding error-prone procedures. Furthermore, the report measures internal reuse, understandability and object-orientedness. It also includes statistics on programming problems found.
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.
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 Summary report includes key size metrics on the code. The report counts the lines, files, modules, procedures, variables, constants and other definitions. Besides total counts, definitions are classified by subtype.
In addition to size metrics, the Summary report also includes information on the age and last modified dates of the source files. This information is useful for understanding when the project has been worked on.
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.
©Aivosto Oy - Project Analyzer Help Contents