Problem detection (code review)

Code review problem list

Project Analyzer does an automated code review to detect programming problems and to suggest improvements. This feature is useful for optimization, quality control and automated coding standards enforcement.

Code review rules
Comment directives
Problem options
Problem reports

Problem types

View the code review rules to read details about the problems. You can also right-click a problem to read what it is about.

  1. Optimization. These problems indicate unoptimal programming and dead code. You can enhance your program's run-time speed and/or memory requirement by fixing these problems.
  2. Style. These problems are related to the programming style. They don't necessarily lead to problems in the short run, but they often lead to worse understandability and errors.
  3. Functionality. These problems affect the run-time functionality of the program.
  4. Metrics is a sub-category of Style. You can set target values for different metrics and monitor if some part of your program exceeds the limits. Read more about metrics. The Enterprise Edition is required to view metrics problems.
  5. .NET compatibility. These problems show incompatibilities between VB6 and VB.NET syntax. The Enterprise Edition is required to view compatibility issues.
  6. Internal. This is a rare problem type that appears if Project Analyzer has found something in the analysis that it cannot handle. Right-click the problem to view a suggested solution.

Severity

Code review rules

How do I see the problems?

How do I fix the problems?

Get a Problem report, and fix your code. The Enterprise Edition includes an Auto-Fix feature that automatically fixes some of the problems, removes dead code and leaves a comment for the problems that are left for you to fix manually.

Why isn't this code shown as a problem?

Sometimes you may notice that Project Analyzer doesn't indicate a problem even if the code looks problematic. There are a few explanations to this.

  1. Project Analyzer detected a reason why you should accept problematic code. For example, you cannot safely remove a piece of seemingly dead code because it may be called implicitly. Or, there's no sense in writing an error handler for an empty procedure.
  2. The code was generated by Visual Studio and you shouldn't change it manually.
  3. A comment directive is in effect.

Read more

Code review rules
Comment directives
Problem options
Problem reports

©Aivosto Oy - Project Analyzer Help Contents