D 2018-07-04T17:04:21.198 L internal-fields N text/x-markdown P f1ba2668778da4b44fa291fd0cc7b0e39d1d15fcfd98f8da96e238779513c325 U mario W 1235 ## Implicit/internal field names When [plugin meta data](wiki/Plugin+Meta+Data) comments get extracted into a hashtable (`$meta.*`), some common attributes might get prepoulated. 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 basenames 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 storel this in an internal field named `$meta.fn` ## # comment: …
… … … … … … … 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 implementatiosn I usually keep it as `$meta.comment` (albeit also used `$meta.doc` in some extractors.) Z 196b17dd0b38e4097143cbdbe30ec852