Code Inspections

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 various severity levels ranging from `Hint` to `Error`. Unless configured otherwise, Rubberduck automatically runs inspections after a parser/resolver cycle completes (regardless of whether the toolwindow is displayed or not), so inspection results are always ready to review when you are. 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 any 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. #### The late binding caveat The term _late binding_ is often misconstrued among Classic-VB developers to stand for creating an object instance using `CreateObject` instead of the `New` keyword. While late-bound code will indeed use `CreateObject` to spawn objects without a compile-time reference to the library that defines this particular type, late binding is actually much more pervasive than that, and can easily be missed. **Late binding occurs whenever a member call is made against `Object` or `Variant`**. When this happens, the VBIDE cannot provide _IntelliSense_ or name completion, and even `Option Explicit` cannot save you from a typo because the member call is not going to be evaluated until run-time - and if the member is then found to not exist that's where you get run-time error 438. Option Explicit Public Sub DoSomething() ActiveWorkbook.Worksheets(1).Rnage("A1").Value = 42 '<~ compiles just fine! End Sub You can avoid such implicit late-binding by declaring a local object variable with an explicit data type. In this case, we are getting a `Worksheet` object from a `Worksheets` collection, but the collection yields an `Object` so any member calls directly chained to it can only be resolved at run-time. By working off a `Worksheet` object, we move this validation back to compile-time and the early-bound realm: Option Explicit Public Sub DoSomething() Dim Target As Worksheet Set Target = ActiveWorkbook.Worksheets(1) Target.Rnage("A1").Value = 42 '<~ compile error! End Sub Rubberduck (and static code analysis in general) works well with **early-bound** code: for best results, avoid coding against `Object` and `Variant`, especially with user code (that is, your own class modules). Just like the Classic-VB compiler, Rubberduck cannot really "see" late-bound member calls, so reference counts may be inaccurate, inspections may fire false positives, and some refactorings (e.g. _Rename_) may not work as expected when the code is (implicitly or not) late-bound. #### About static code analysis Not all inspections are created equal! While it can probably be generally agreed upon that a missing `Option Explicit` statement _should_ be reported at `Error` level, other inspections such as _use of Hungarian Notation_ or _implicit access modifier_ are more debatable, and rightly so. Rubberduck strives to explain its inspection results and provide as much information as possible about what it deems flag-worthy, but there can never be 100% certainty across an entire project, that a given inspection result is accurate or warranted. It is important to never treat any inspection results (Rubberduck's, or any other add-in's) as anything more than an automated tool flagging a _potential_ issue (in the case of a _warning_) or merely _making an observation_ (in the case of a _suggestion_ or a _hint_) about the code.