-
Notifications
You must be signed in to change notification settings - Fork 301
Inspections xml doc
Since v2.4.1.4719, build assets include Rubberduck.CodeAnalysis.xml
, a file generated on build, containing all the XML comments in Rubberduck.CodeAnalysis
.
The project's website is now downloading this xml file to extract the documentation for all types whose name ends with Inspection
. When invalidating its cache, the website attempts to pull the xml asset from the latest "green-release" off the [master] branch, and the same xml asset from the latest "pre-release" tag off the [next] branch; inspections that exist in [next] but not in [master] will be marked in the inspections/list page with a "PreRelease" label (unless no xml asset is found in [master], as is currently the case as of this writing).
In order for this to work, xml documentation for inspection classes must follow a number of rather strict rules:
-
Rubberduck's parser must be able to parse the VBA code examples; keep in mind that precompiler directives (e.g.
#If
,#Const
, etc.) are handled in a separate parser - the website does not "pre-process" the code samples, so precompiler directives are not allowed. - Not all inspections need or even can have examples, and that's fine.
- Website does not honor any html formatting present in the xml documentation.
The structure of an inspection's xml-doc comment must be as follows:
<summary hidden="false">
short, single-sentence description of the inspection that comfortably reads in IntelliSense.
</summary>
<why>
a paragraph that describes the reasoning of the inspection in details.
</why>
<reference name="RequiredLibrary" />
<hostapp name="EXCEL.EXE" />
<example hasresult="true">
<module name="Class1" type="Class Module">
<![CDATA[
Public Sub CodeExample()
'code example
End Sub
]]>
</module>
<module name="Module1" type="Standard Module">
<![CDATA[
Public Sub DoSomething()
'code example
End Sub
]]>
</module>
</example>
<example hasresult="false">
<![CDATA[
Public Sub CodeExample()
'code example
End Sub
]]>
</example>
The <summary>
tag can have a hidden
attribute; if the value is "true"
, the inspection will not appear on the website. This attribute should be reserved for Easter Egg inspections.
The <reference>
tag is needed when the inspection has a [RequiredLibrary("LibraryName")]
attribute; the website uses this information to indicate that the inspection will only run when the specified library is referenced. Hence, there should be a <reference>
tag for each RequiredLibraryAttribute
decorating an inspection type.
If an inspection has a [RequiredHost("HOST.EXE")]
attribute, it should have a <hostapp name="HOST.EXE" />
tag.
<example>
tags must have a hasResult
attribute with a value of "true"
or "false"
, and may contain either:
- one or more
<module>
tags that contain<![CDATA[{code block}]]>
tag that begins and ends on a new line; - nothing other than a
<![CDATA[{code block}]]>
tag that begins and ends on a new line:
<example hasResult="true">
<![CDATA[
Public Sub DoSomething()
End Sub
]]>
</example>
If a <module>
tag is used for one example, use it in all examples for that inspection. You may use a name
attribute to label the module block. If the module type is relevant, specify a type
attribute value.
Only one <![CDATA[{code block}]]>
block may appear under any given <example>
tag, unless it's wrapped in a <module>
tag.
<remarks>
tags are also picked up when present.
rubberduckvba.com
© 2014-2021 Rubberduck project contributors
- Contributing
- Build process
- Version bump
- Architecture Overview
- IoC Container
- Parser State
- The Parsing Process
- How to view parse tree
- UI Design Guidelines
- Strategies for managing COM object lifetime and release
- COM Registration
- Internal Codebase Analysis
- Projects & Workflow
- Adding other Host Applications
- Inspections XML-Doc
-
VBE Events