D 2018-07-04T17:30:39.178
L internal-fields
N text/x-markdown
P 2cde645101165a0c164179bb98cf2d6956e0fb3d700e3bab298733f6d6b7ff3e
U mario
W 1234
## Implicit/internal field names
When [plugin meta data](wiki/Plugin+Meta+Data) comments get extracted into a hashtable (`$meta.*`), some common attributes might get populated. Either implied from the filename, or from predefined defaults.
## # id: basename
With e.g. the [depends:](wiki/depends) field plugins can reference each other. And they typically just list basenames, not full paths. Because the point of PMD is to abstract filenames from plugin names.
# fn: src/plugin/featurename.rb
# id: featurename
Albeit one could use a literal `# id:` override in scripts, it's probably best to avoid ambigious basenames. For the scope of one application API all plugin identifiers should be unique.
## # fn: .../src/plugin/filename.rb
When a script gets parsed, it's often necessary to retain its exact location. For brevity, I'd usually store this in an internal field named `$meta.fn`
## # comment: …<br>… … … … … … …
The remainder of the topmost comment block (after all PMD key:value fields) is meant to contain a longer [description](wiki/description). And for my implementations I usually keep it as `$meta.comment` (albeit also used `$meta.doc` in some extractors.)
Z 1d8de84e86f15ee5540429dea7e4d7b4