Extra prefix/suffix rules for package contents

[imd1]

Currently prefix/suffix rules for a number of items (constants, types and sub types) are applied whether they are defined inside a package (normally in a separate file) or inside architectures or wherever

Let's just consider constants for illustration

Propose taking the current single rule pair e.g. constant_015/constant_600 and replacing/supplementing them with multiple rules according to where they are defined, which would take precedence of the single rules.

e.g. constant_601 = prefix for constants inside packages
constant_602 = suffix for constants inside packages
constant_015 = prefix for constants outside packages
constant_600 = suffix for constants outside packages

OR depreciating the single rules in favor of a comprehensive set of mutliple rules

[jeremiah-c-leary]

What would you think of adding an option to the existing rules instead of a separate rule. Something like package_prefixes.

{
  "rule": {
    "constant_015": {
      "indentSize": 2,
      "phase": 7,
      "disable": true,
      "fixable": false,
      "severity": "Error",
      "prefixes": [
        "c_"
      ],
      "package_prefixes": [
        "pc_"
      ]
    }
  }
}

Not sure that option is better than a separate rule.

Thoughts?

--Jeremy

[imd1]

I'm struggling to remember why I wanted this enhancement, but I think it relates to my prefix/suffix auto correction scripting. It would be useful for the error log to tell me whether the violation occurred in a package rather than an architecture, and so I do want a different rule number for each

[jeremiah-c-leary]

I know at my work a manager wanted to have generics in packages to have a different prefix than one "locally" declared in an architecture.

You could see someone wanting to have different prefixes based on scope: architecture, process, block, package, package_body, procedure, function, etc...