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 bang notation, formally known as dictionary access expression.
Default severity: Warning
A dictionary access expression looks like a strongly typed call, but it actually is a stringly typed access to the parameterized default member of the object.
Identifies the use of bang notation, formally known as dictionary access expression, for which a recursive default member resolution is necessary.
Default severity: Warning
A dictionary access expression looks like a strongly typed call, but it actually is a stringly typed access to the parameterized default member of the object. This is especially misleading if the parameterized default member is not on the object itself and can only be reached by calling the parameterless default member first.
Identifies the use of bang notation, formally known as dictionary access expression, for which the default member is not known at compile time.
Default severity: Warning
A dictionary access expression looks like a strongly typed call, but it actually is a stringly typed access to the parameterized default member of the object. This is especially misleading the default member cannot be determined at compile time.
Locates places in which a value needs to be accessed but an object variables has been provided that does not have a suitable default member.
Default severity: Warning
The VBA compiler does not check whether the necessary default member is present. Instead there is a runtime error whenever the runtime type fails to have the default member.
Warns about variables that are never assigned.
Default severity: Warning
A variable that is never assigned is probably a sign of a bug. This inspection may yield false positives if the variable is assigned through a ByRef parameter assignment, or if UserForm controls fail to resolve, references to these controls in code-behind can be flagged as unassigned and undeclared variables.
Warns about variables that are never referenced.
Default severity: Warning
A variable can be declared and even assigned, but if its value is never referenced, it's effectively an unused variable.
Warns about variables declared without an explicit data type.
Default severity: Warning
A variable declared without an explicit data type is implicitly a Variant/Empty until it is assigned.
Warns about properties that don't expose a 'Property Get' accessor.
Default severity: Suggestion
Write-only properties are suspicious: if the client code is able to set a property, it should be allowed to read that property as well. Class design guidelines and best practices generally recommend against write-only properties.