Static code analysis can find hundreds of opportunities in VBA code.
Rubberduck builds its own internal representation of the code, and then proceeds to analyze it. Each individual inspection can easily be disabled, or configured to issue inspection results at different severity levels ranging from Hint to Error.
Use the Inspection Results toolwindow to review Rubberduck’s findings, search, filter, regroup results by inspection, location, type, or severity. Each inspection result comes with a detailed description of what’s being flagged and why, so you can make an enlightened decision.
Unless configured otherwise, Rubberduck automatically runs inspections after the a parser/resolver cycle completes (regardless of whether the inspection results toolwindow is displayed or not).
For the best experience, it would be recommended to first try Rubberduck with an empty project, add a new module, and write, say, a loop that counts 1 to 10 and outputs to the debug pane - then to parse that and review the inspection results; carefully review the inspection settings, and consider disabling the inspections that irreconcilably clash with your preferences: use meaningful names alone can easily produce hundreds upon hundreds of results if you’re not that much into using vowels, or if you, say, prefix all your variable names; these inspections can be re-enabled anytime you’re ready!
This tab lists all items found in the .xml documentation assets from the latest pre-release build. To modify this content, a pull request must be merged into the [next] branch.
Identifies the use of indexed default member accesses.
Default severity: Warning
An indexed default member access hides away the actually called member.
Identifies the use of indexed default member accesses that require a recursive default member resolution.
Default severity: Warning
An indexed default member access hides away the actually called member. This is especially problematic if the corresponding parameterized default member is not on the interface of the object itself.
Identifies the use of indexed default member accesses for which the default member cannot be determined at compile time.
Default severity: Warning
An indexed default member access hides away the actually called member. This is especially problematic if the default member cannot be determined from the declared type of the object. Should there not be a suitable default member at runtime, an error 438 'Object doesn't support this property or method' will be raised.
Identifies obsolete 16-bit integer variables.
Default severity: Hint
Modern processors are optimized for processing 32-bit integers; internally, a 16-bit integer is still stored as a 32-bit value. Unless code is interacting with APIs that require a 16-bit integer, a Long (32-bit integer) should be used instead.
Identifies uses of 'IsMissing' involving non-variant, non-optional, or array parameters.
Default severity: Warning
'IsMissing' only returns True when an optional Variant parameter was not supplied as an argument. This inspection flags uses that attempt to use 'IsMissing' for other purposes, resulting in conditions that are always False.
Identifies uses of 'IsMissing' involving a non-parameter argument.
Default severity: Warning
'IsMissing' only returns True when an optional Variant parameter was not supplied as an argument. This inspection flags uses that attempt to use 'IsMissing' for other purposes, resulting in conditions that are always False.
Identifies line labels that are never referenced, and therefore superfluous.
Default severity: Warning
Line labels are useful for GoTo, GoSub, Resume, and On Error statements; but the intent of a line label can be confusing if it isn't referenced by any such instruction.
Warns about member calls against an extensible interface, that cannot be validated at compile-time.
Default severity: Warning
Extensible COM types can have members attached at run-time; VBA cannot bind these member calls at compile-time. If there is an early-bound alternative way to achieve the same result, it should be preferred.
Warns about a malformed Rubberduck annotation that is missing an argument.
Default severity: Error
Some annotations require arguments; if the argument isn't specified, the annotation is nothing more than an obscure comment.
Indicates that a Rubberduck annotation is documenting the presence of a VB attribute that is actually missing.
Default severity: Warning
Rubberduck annotations mean to document the presence of hidden VB attributes; this inspection flags annotations that do not have a corresponding VB attribute.
Indicates that a hidden VB attribute is present for a member, but no Rubberduck annotation is documenting it.
Default severity: Warning
Rubberduck annotations mean to document the presence of hidden VB attributes; this inspection flags members that do not have a Rubberduck annotation corresponding to the hidden VB attribute.
Indicates that a hidden VB attribute is present for a module, but no Rubberduck annotation is documenting it.
Default severity: Warning
Rubberduck annotations mean to document the presence of hidden VB attributes; this inspection flags modules that do not have a Rubberduck annotation corresponding to the hidden VB attribute.
Warns about module-level declarations made using the 'Dim' keyword.
Default severity: Suggestion
Private module variables should be declared using the 'Private' keyword. While 'Dim' is also legal, it should preferably be restricted to declarations of procedure-scoped local variables, for consistency, since public module variables are declared with the 'Public' keyword.
Indicates that a user module is missing a @Folder Rubberduck annotation.
Default severity: Suggestion
Modules without a custom @Folder annotation will be grouped under the default folder in the Code Explorer toolwindow. By specifying a custom @Folder annotation, modules can be organized by functionality rather than simply listed.
Locates module-level fields that can be moved to a smaller scope.
Default severity: Hint
Module-level variables that are only used in a single procedure can often be declared in that procedure's scope. Declaring variables closer to where they are used generally makes the code easier to follow.
Flags parameters declared across multiple physical lines of code.
Default severity: Suggestion
When splitting a long list of parameters across multiple lines, care should be taken to avoid splitting a parameter declaration in two.
Flags declaration statements spanning multiple physical lines of code.
Default severity: Warning
Declaration statements should generally declare a single variable.
Warns about 'Function' and 'Property Get' procedures whose return value is not assigned.
Default severity: Error
Both 'Function' and 'Property Get' accessors should always return something. Omitting the return assignment is likely a bug.
Warns about assignments that appear to be assigning an object reference without the 'Set' keyword.
Default severity: Error
Omitting the 'Set' keyword will Let-coerce the right-hand side (RHS) of the assignment expression. If the RHS is an object variable, then the assignment is implicitly assigning to that object's default member, which may raise run-time error 91 at run-time.
Identifies places in which an object is used but a procedure is required and a default member exists on the object.
Default severity: Warning
Providing an object where a procedure is required leads to an implicit call to the object's default member. This behavior is not obvious, and most likely unintended.