Improve handling of guideline flavors

[darkwisebear]

Background

The SCRC coding guidelines provide different flavors of guidelines. Currently, there is defect and subset, which usually tackle the same language shortcoming, but with a different strategy. Usually, it is not desirable to have more than one flavor used in a certain project. Therefore, we want to provide a way how to easily spot the flavor of a guideline and we also want a way to easily find the guidelines that tackle the same problem but with a different strategy.

Current approach

At the moment, the flavors are expressed in terms of rule tags. While that allows for easy filtering, this approach does have shortcomings:

• Tags are optional. It is therefore possible that one forgets to add this tag since there is no explicit hint that this decision has to be made.
• There is no link to the same-but-different rules

Suggested approach

• Promote the flavor tag to a separate property and make it mandatory (including an option to "not have a flavor")
• Add an optional property that becomes mandatory in case there is an explicit flavor set that links to one or more similar rules with a different strategy.

[AlexCeleste]

I can imagine that some users might want to disable the subset rules and just have the defect rules if they're happy to run the more powerful checks that might imply

In general, users who choose to enable the subset rules will be doing so to avoid the underlying defect though, right? They'll just be more confident that they are correctly avoiding it. Ideally, a project set up to use subset rules will have full compliance with defect rules by implication, right?

In particular I can see some utility in a user being able to Deviate a subset rule while retaining flow-analysis-based protection against the underlying defect.

---

That said, I don't think the above point actually impacts the document structure 😅 since it's up to the user, the one applying the profile filter, whether the subset label implies including the rules with the defect label as well, or not.

However, I wouldn't want to design in an assumption that the profile will always be symmetrical.

[darkwisebear]

Makes sense. So instead of talking about "flavors" it's more like a "tier" approach where one rule acts as a stricter version of the other, lower tier rule.

This means that if we're discussing rules with several tiers we / the author needs to make sure that the more restrictive rule always is a superset of the defect rule. As you already said, this is probably not a big deal since the subset rule tries to carve out the language element that causes the defect rather than "just" raising attention to the actual misuse.

[darkwisebear]

Discussion about this topic can be found at https://docs.google.com/document/d/1Gs6UdrZgARe3JMQ0c3TOfwAsYZpuqYflIAqakH3LRys/edit?tab=t.0. Will be distilled in this or other issues.