Sub ProcedureWithoutErrors()' This procedure needs no error handling
End Sub
Comment directives let you ignore code review problems. When you wish to ignore problems in a certain section of code, you write a comment directive in your code. Comment directives are specially formatted comments. Example: '$PROBHIDE ALL hides all problems on a line.
With comment directives you can:
'$ directive [ : directive [ : directive ...]]
Comment directives always start with '$. The '$ prefix marks the start of a comment directive line. Rem $ is not acceptable as a comment directive.
You can put multiple directives on one line by separating them with a colon ( : ). The available directives are PROBHIDE, PROBSHOW, END and USED.
The PROBHIDE directive hides problems of one or more types. Use it to disable problem detection at locations you don't want to change. Syntax:
PROBHIDE <problem type> [<problem type> ...] [EXCEPT <problem type> [<problem type> ...] ] [BEGIN]
| <problem type> | Problem type(s) to hide. See the Code review rules for names of single problem types. You can also use combination types, see below. You can list any number of problem types separated by space. |
|---|---|
| EXCEPT | Optional. Problems types listed after this parameter are not affected by the rule. |
| BEGIN | Optional. Starts a BEGIN...END block. The directive affects all code until a matching '$ END directive or end-of-file. If BEGIN is omitted, the directive affects just one line of code. See Scope |
| Combination type | Explanation |
|---|---|
| ALL | All problems |
| SEVERE | Severe problems |
| WARN, WARNING | Warnings |
| INFO, INFORMATION | Informational problems |
| OPT, OPTIMIZATION | Optimization related problems (also includes DEAD) |
| DEAD | Dead code related problems |
| STYLE | Style related problems (also includes METRICS) |
| SCOPE | Combination of EXCESS_SCOPE, NO_SCOPE, MEMBER_SCOPE and GLOBAL |
| METRICS | Metrics related problems |
| FUNC, FUNCTIONALITY | Functionality related problems |
Read the Code review rules for the names of individual problem types.
A procedure does not require an error handler. Hide the "Error handler missing" problem for that procedure but show it everywhere else.
'$ PROBHIDE NO_ERROR_HANDLER
Sub ProcedureWithoutErrors()
' This procedure needs no error handling
End Sub
A procedure is dead at the moment but you don't want to remove it. You want to flag the procedure live without hiding any other dead code related problems. Notice how the syntax affects just the next line (the line with the dead procedure problem). Any other lines are not affected and the dead variable problem will thus be shown. Notice that hiding a dead procedure problem propagates down along the call tree.
'$ PROBHIDE DEAD
Sub DeadProcedure()
' This procedure should be kept for later use
Dim DeadVariable As Integer ' But this variable should be removed
Call ChildProcedure
End Sub
Sub ChildProcedure()
' This procedure shows up as live because it's called by DeadProcedure which was flagged live
End Sub
Hide all problems classified as "warning" or "information" until end-of-file.
'$ PROBHIDE WARNING INFORMATION BEGIN
code with problems
that I want to hide
Hide all problems in a range of code between BEGIN and END. Keep showing dead code related problems at all locations.
'$ PROBHIDE ALL EXCEPT DEAD BEGIN
code with problems
to hide
'$ END
show all problems after this point
A Goto statement is acceptable at a certain location. Hide the problem on that specific line. There are two alternative ways to write the same directive: write the comment either on the line with the problem or add it on a new line immediately above it.
Goto 1999 '$ PROBHIDE GOTO
'$ PROBHIDE GOTO
Goto 1999
Enables (shows) problems that would otherwise be hidden by PROBHIDE. Syntax:
PROBSHOW <problem type> [<problem type> ...] [EXCEPT <problem type> [<problem type> ...] ] [BEGIN]
The syntax is similar to that of PROBHIDE. You should use PROBSHOW only inside a PROBHIDE BEGIN ... END block.
Hide all problems in a class, but enable dead code problems after class declarations to remove any dead procedures and local variables/constants.
'$ PROBHIDE ALL BEGIN
Dim x, y
Const PI = 3.14
Declare Function ChooseFont Lib "comdlg32.dll" Alias "ChooseFontA" (pChoosefont As CHOOSEFONT) As Long
'$ PROBSHOW DEAD BEGIN
Sub MyProc ( x )
End Sub
...
Ends a BEGIN...END directive block. See Scope below for more information.
This obsolete directive marks things as being in use. It is provided for backward compatibility with older Project Analyzer versions. You should not use this directive any more since future versions may not support it. Project Analyzer replaces it internally as follows:
USED => PROBHIDE DEAD
USED PROC => PROBHIDE DEAD_PROC
USED PARAM not supported, use PROBHIDE DEAD EXCEPT DEAD_PROC instead.
How do you work out where to put the directives and what code they will then affect? First of all, look at the problem icons in the hypertext view of Project Analyzer. Your comment directives should be placed to affect the lines with the icons. If your directives don't seem to work, pay attention to the exact line and the scope you're using. There are 4 alternative ways to define the scope of a comment directive.
'$ PROBHIDE DEAD
Dim MyVariable As Integer
A directive on an otherwise empty line affects the immediately following line. In this case, MyVariable is not reported dead.
Dim MyVariable As Integer '$ PROBHIDE DEAD
A directive after the code on a given line affects that line. In this case, MyVariable is not reported dead.
'$ PROBHIDE DEAD BEGIN
Dim MyVariable As Integer
Dim Text As String
'$ END
The directive affects all code between the BEGIN and the END directive. In this case, MyVariable and Text are not reported dead.
You can nest multiple BEGIN...END blocks. You may also omit the END directive. In that case, the block ends at end-of-file.
'$ PROBHIDE DEAD IN_THIS_FILE
To hide problems in an entire file, regardless of which line they affect, use the IN_THIS_FILE scope. You can put this keyword anywhere in the file to make a directive apply to all lines in the file, also lines before the directive. It is especially useful to hide problems at the start of the file when you want to use that area for a module header comment block and not for a directive.
Directives that come later have higher precedence. Thus, you can always override a previous directive by writing a new directive after it. This happens regardless of the scope definition. For example, you can have a '$ PROBHIDE DEAD BEGIN early in the file and then override it with a '$ PROBSHOW ALL IN_THIS_FILE later. In this case, the later PROBSHOW has higher precedence and will override the PROBHIDE.
If you don't want to override previous settings, use the EXCEPT keyword. In the above example, '$ PROBSHOW ALL EXCEPT DEAD IN_THIS_FILE would show all other problems but not have any effect on dead code related problems, which would follow earlier directives.
You can flag a procedure as live code in several ways. The recommended way is by '$ PROBHIDE DEAD or '$ PROBHIDE DEAD_PROC.
Hiding a dead procedure problem flags the affected procedure as live code. What is more, also the procedures it calls are flagged live, down along the entire call tree. Consider a call tree such as A -> B -> C. If you flag A as a live procedure, also B and C will show up as live. Thus, using ' $PROBHIDE to hide one dead procedure also propagates downwards in the call tree. You can mark just the root procedure as live and Project Analyzer will take care of the rest. The call tree propagation only affects procedures. Variables, classes or any other code is not affected.
There's a command line option that tells Project Analyzer to ignore any comment directives. Start Project Analyzer like this: project.exe /NOCDIRECTIVES. Use this option to detect all problems even if $PROBHIDE has been used to hide some of them. You can also use it if your code happens to have existing comment lines that start with $PROBHIDE, $PROBSHOW or $USED.
PROJECT_ANALYZER is a built-in "compiler constant" that allows you to tweak the code analysis.You can add missing definitions or exclude sections from being analyzed. During code analysis, PROJECT_ANALYZER=True. To Visual Basic, PROJECT_ANALYZER=False.
PROJECT_ANALYZER is not a comment directive. It's a constant for #If..#ElseIf..#Else..#End If.
The following trick lets you run your code with late binding, but analyze it as if it were early-bound.
#If PROJECT_ANALYZER Then Dim o As MyClass ' Analyze early-bound calls only #Else Dim o As Object ' Run with late binding #End If
The next trick lets you write code that won't be analyzed at all. You can also add code for the purpose of code analysis only.
#If PROJECT_ANALYZER Then FakeCall ' Analyze what would happen with this call #Else SecretCall ' This runs but won't be analyzed #End If
Versions. Suppose your code compiles two versions of the same program. To compile version 1, you set VERSION=1 in your project settings. To compile the other version, you set VERSION=2. Now, you exclude and include sections of code with #If to compile the 2 versions. This causes problems in the analysis, because Project Analyzer should read your code in its entirety and not just one of the versions.
The following trick lets you compile several versions of your program while keeping Project Analyzer analyzing the full code.
#If VERSION=1 Or PROJECT_ANALYZER Then Version 1 code goes here #End If #If VERSION=2 Or PROJECT_ANALYZER Then Version 2 code goes here #End If
Tweak metrics. Suppose you have a large section of generated code that shouldn't be counted in the logical lines of code (LLOC) metric, because it exaggerates the size of your program. By adding the generated code in a False block you exclude it from LLOC, even when it still compiles and runs just fine.
#If Not PROJECT_ANALYZER Then excluded code goes here #End If
©Aivosto Oy - Project Analyzer Help Contents