It is possible to define COM types that have naming conflicts in VBA.
For example, unlike VBA (which disallows Array as a valid class name), the mscorlib COM library exposes a .NET Array class.
You can't declare a variable of type Array, because it conflicts with a reserved word:
Dim arr As Array '<-- Syntax Error
It is possible to declare a variable of type Array, by using square brackets:
Dim arr As [Array]
But the VBE pretty-printer autocorrects that to a valid VBA statement (despite it being identical to the syntax error version above):
Dim arr As Array
That line remains valid until it is edited or indented, or the module is exported and imported, at which point it becomes a syntax error again.
The problem can be avoided by qualifying the type with the library name:
Dim arr As mscorlib.Array
Rubberduck should identify these fragile keyword collisions, and qualify them appropriately.
These naming collisions have the potential to break the project when the following RD features are applied/exercised : Source Control, Indenter & Refactorings. IMO, this inspection should have a high importance, and perhaps even be a pre-requisite quickfix, before other features should/can be exposed/used.
ThunderFrame
commented
7 years ago
It is possible to define COM types that have naming conflicts in VBA.
For example, unlike VBA (which disallows
Arrayas a valid class name), themscorlibCOM library exposes a .NETArrayclass.You can't declare a variable of type
Array, because it conflicts with a reserved word:Dim arr As Array '<-- Syntax ErrorIt is possible to declare a variable of type
Array, by using square brackets:Dim arr As [Array]But the VBE pretty-printer autocorrects that to a valid VBA statement (despite it being identical to the syntax error version above):
Dim arr As ArrayThat line remains valid until it is edited or indented, or the module is exported and imported, at which point it becomes a syntax error again.
The problem can be avoided by qualifying the type with the library name:
Dim arr As mscorlib.ArrayRubberduck should identify these fragile keyword collisions, and qualify them appropriately.
These naming collisions have the potential to break the project when the following RD features are applied/exercised : Source Control, Indenter & Refactorings. IMO, this inspection should have a high importance, and perhaps even be a pre-requisite quickfix, before other features should/can be exposed/used.