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.
Locates procedures that are never invoked from user code.
Default severity: Warning
Unused procedures are dead code that should probably be removed. Note, a procedure may be effectively "not used" in code, but attached to some Shape object in the host document: in such cases the inspection result should be ignored.
Locates places in which a procedure needs to be called 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.
Flags MSForms controls being accessed from outside the UserForm that contains them.
Default severity: Hint
MSForms exposes UserForm controls as public fields; accessing these fields outside the UserForm class breaks encapsulation and couples the application logic with specific form controls rather than the data they hold. For a more object-oriented approach and code that can be unit-tested, consider encapsulating the desired values into their own 'model' class, making event handlers in the form manipulate these 'model' properties, then have the code that displayed the form query this encapsulated state as needed.
Identifies Property assigment references where Set or Let Property Members do not exist.
Default severity: Warning
In general, the VBE editor catches this type of error and will not compile. However, there are a few scenarios where the error is overlooked by the compiler and an error is generated at runtime. To avoid the runtime error scenarios, the inspection flags all assignment references of a read-only property.
Identifies redundant ByRef modifiers.
Default severity: DoNotShow
This inspection will not run by default, it must be manually enabled in Code Inspections configuration settings.
Out of convention or preference, explicit ByRef modifiers could be considered redundant since they are the implicit default. This inspection can ensure the consistency of the convention.
Identifies redundant module options that are set to their implicit default.
Default severity: Hint
Module options that are redundant can be safely removed. Disable this inspection if your convention is to explicitly specify them; a future inspection may be used to enforce consistently explicit module options.
Identifies auto-assigned object declarations.
Default severity: Suggestion
Auto-assigned objects are automatically re-created as soon as they are referenced. It is therefore impossible to set one such reference to 'Nothing' and then verifying whether the object 'Is Nothing': it will never be. This behavior is potentially confusing and bug-prone.
Locates assignments to object variables for which the RHS does not have a compatible declared type.
Default severity: Warning
The VBA compiler does not check whether different object types are compatible. Instead there is a runtime error whenever the types are incompatible.
Identifies identifiers that hide/"shadow" other identifiers otherwise accessible in that scope.
Default severity: DoNotShow
This inspection will not run by default, it must be manually enabled in Code Inspections configuration settings.
Global namespace contains a number of perfectly legal identifier names that user code can use. But using these names in user code effectively "hides" the global ones. In general, avoid shadowing global-scope identifiers if possible.
Locates ThisWorkbook.Worksheets and ThisWorkbook.Sheets calls that appear to be dereferencing a worksheet that is already accessible at compile-time with a global-scope identifier.
Default severity: Suggestion
Sheet names can be changed by the user, as can a worksheet's index in ThisWorkbook.Worksheets. Worksheets that exist in ThisWorkbook at compile-time are more reliably programmatically accessed using their CodeName, which cannot be altered by the user without accessing the VBE and altering the VBA project.
This inspection will only run if the Excel library is referenced.