LC0092 (NamingPattern): align affix handling with the shared MandatoryAffixes helper?

[Arthurvdv]

@MODUSCarstenScholling I'd like your view on aligning affix handling across rules.

Context

For #436 we introduced a shared ALCops.Common.Helpers.MandatoryAffixes helper, now used by LC0054 and PC0021. It mirrors the SDK's own affix validation (GetMandatoryNameAffixes / RuleIdentifiersMustHaveValidAffixes) with loose semantics: every configured value from mandatoryPrefix, mandatorySuffix, and mandatoryAffixes is a valid candidate at either end of a name. It strips at most one affix per end, trims residual whitespace, and never produces an empty name.

LC0092 has its own affix logic that sits in between:

• merges mandatoryPrefix + mandatoryAffixes, but ignores mandatorySuffix
• tries each candidate at both ends (so it's already partially loose)
• strips at most one affix total, not one per end

Question

Should LC0092 adopt the shared helper (full SDK-loose semantics), or is there value in keeping a stricter/explicit interpretation where prefix means start-only and suffix means end-only?

Arguments for aligning (loose, shared helper):

• One behavior across LC0054, LC0092, PC0021; one place to fix bugs
• Matches what AppSourceCop itself accepts, so we never flag names Microsoft considers compliant
• Fixes the current mandatorySuffix blind spot in LC0092

Arguments for keeping/tightening:

• A naming rule arguably should be opinionated: a prefix showing up at the end of a name may be worth flagging even if AppSourceCop tolerates it
• Loose stripping can mask genuine naming issues (e.g. prefix "ABC" stripped from "Rebate ABC")

On long-term relevance: namespaces reduce the need for affixes on object names, but AppSourceCop still mandates affixes on fields in table extensions, enum value extensions, and other extension-object members, which namespaces don't cover. So this won't resolve itself soon.

We're keeping LC0092 as-is for now; no urgency. Open to either direction, including a middle ground (adopt the helper but fix only the mandatorySuffix gap with strict end-matching).

---

Generated with Claude Fable 5

[MODUSCarstenScholling]

@Arthurvdv I’d favor aligning LC0092 with LC0054 and PC0021 by using the shared MandatoryAffixes helper. Initially, this should use the SDK-compatible loose semantics so that LC0092 does not report names that AppSourceCop considers valid.

I would suggest asking Microsoft for an alignment on their side, but they would argue with changes in well-known behavior.

At the same time, we could introduce an internal strictAffixes switch, defaulting to false, and implement the stricter behavior behind it:

• mandatoryPrefix matches only at the start;
• mandatorySuffix matches only at the end;
• mandatoryAffixes remains valid at either end (anywhere)

This gives us consistent behavior and fixes the current mandatorySuffix gap now, while preserving the option to expose strict affix validation as a configurable rule setting later.