[RULE REQUEST] Recommend rule friendly name

[ghost]

Rule metadata

• SARIF2025

• ProvideRuleFriendlyName

• note

• Full description

  Each analysis rule should provide a "friendly name" in its 'name' property, in addition to the stable, opaque identifier in its 'id' property. This helps users see at a glance the purpose of the analysis rule. For uniformity of experience across all tools that produce SARIF, the friendly name should be a single Pascal identifier, for example, 'ProvideRuleFriendlyName'.

• User-facing strings:

  • FriendlyNameMissing

    {0}: The rule '{1}' does not provide a "friendly name" in its 'name' property. The friendly name should be a single Pascal identifier, for example, 'ProvideRuleFriendlyName', that helps users see at a glance the purpose of the analysis rule.

  • FriendlyNameNotAPascalIdentifier

    {0}: '{1}' is not a Pascal identifier. For uniformity of experience across all tools that produce SARIF, the friendly name should be a single Pascal identifier, for example, 'ProvideRuleFriendlyName'.

[eddynaka]

@lgolding , how do you imagine that we could validate if the string is in pascal or not?

[ghost]

@eddynaka One or more repetitions of a capital letter followed by one or more lower-case letters.

^(\p{Lu}\p{Ll}+)+$

And I suppose we should allow digits in the lower-case part, so

^(\p{Lu}[\p{Ll}\p{Nd}]+)+$

[eddynaka]

For the message FriendlyNameMissing, are we going to point to the rule, right? If yes, aren't we missing the tag '{0}'?

[ghost]

Yes, we need the {0}.

[ghost]

Breaking: I realized that this should be combined with the existing SARIF2012.ProvideHelpUris to form the less granular rule SARIF2012.ProvideRuleProperties. This will cover friendly name, help URI, and whatever other rule properties we require in future.

@eddynaka is doing this now.

@michaelcfanning FYI