Even the most experienced Visual Basic programmer does not write perfect code — including me! While your program may run as it should, without bugs or errors, the source code may still be riddled with programming missteps that reduce efficiency and make the program harder to modify and maintain. Wouldn't it be nice to have a tireless master programmer looking over your shoulder to help catch these problems? Aivosto Oy's Project Analyzer 7.1 may be the next best thing, serving as a tireless and automated helper who can help you to catch most of these code gaffes.

Analyzing a Project

The analysis process could hardly be simpler. Use the Open command to locate and open the Visual Basic project. The analysis process detects all problems in the source code, but which problems are displayed is determined by the current problem filter setting (I'll get to this soon). Project Analyzer works with Visual Basic code from all the way back to version 3 up to and including Visual Basic.Net 2003.

By default, Project Analyzer analyzes all the source code in a project, but you have the option of omitting certain files. That's useful when you are working on a large project and know that only certain parts have changed since the previous analysis.

The code analysis is potentially of interest to any Visual Basic 6 programmer and covers a wide range of bases. Perhaps most interesting is its dead code analysis. Dead code is, broadly speaking, code that is unnecessary and unused. It adds size to your program, increases compilation time, and occupies extra memory during both development and execution. While some projects may have relatively little dead code, you might be surprised at others. In particular, complex, multi-programmer projects are prone to this problem.

A few of the many kinds of dead code include:

• A dead variable is declared but never written or read. A semi-dead variable is written but never read.
• A dead procedure or method is never called or it is called only from dead callers.
• A dead parameter is passed to a procedure or method but not used by it.
• A dead class is not used anywhere. A semi-dead class may be used as a data type but is never instantiated.
• A dead event does not fire.

All editions of Project Analyzer provide dead code analysis, but only the Enterprise edition can automate dead code removal, by either deleting the code or commenting it out.

Dead code is just one type of problem that Project Analyzer flags. The main problem categories that Project Analyzer works with are:

• Optimizations. These include dead code as well as other problems that have a negative impact on program execution speed or memory usage.
• Style. Items related to programming style that do not cause execution errors, per s&eactute;, but may result in understandability and code maintenance issues in the future.
• Functionality. These problems affect the run-time functionality of the program.
• Metrics. This is a sub-category of style that provides information on the code that can aid in quality control and project management, such as lines of code, number of comments, code complexity, code understandability, and many others.

Each problem that Project Analyzer finds is flagged for type and is also flagged as being severe, a warning, or informational, depending on how important it is to fix. The recommended approach is, as you might expect, to start with the severe problems and go from there.

Project Analyzer also analyzes and displays call trees, both forward and backward. From the current location in code, a forward call tree shows all procedures that could be called from that location either directly or indirectly. A backward call tree shows all the locations from which the current code could be called. Call trees can be displayed either as hierarchical lists or graphically. This ability to analyze call trees can be a real blessing when execution is taking unexpected paths through your code. It can also be a help in detecting spaghetti code. The call tree feature also lets you view file dependencies in your project.

Analysis Flexibility

One strength of Project Analyzer is its high level of flexibility. You can set options for many aspects of program operation to tailor it to precisely suit your needs. For example, you can select from several levels of pre-defined problem filters. You can opt to view all problems, only those related to functionality, or only dead code, just to mention a few examples. You can also define your own problem filters, to show or ignore precisely those code problems that are of interest to you.

Customization extends to some minor but useful things that make this program shine, such as custom report footers, source code display format, and the ability to link HTML reports to a style sheet. With so many options, it's a good thing that the program provides sensible defaults for everything.

Another feature that is very useful in team programming environments is the ability to import and export options. A team supervisor can create a custom problem definition and export it for use by all programmers on the team.