Enhancement request: Implement regular expression matching for flexibility to support a variety of coding standards.

[DavidotNet]

Feature request. Enhance the settings configuration to accept regular expression (RegEx) strings, and the enhance the identifier validation logic to apply RegEx matching; e.g. PREFIX_LOCAL_VARIABLE_NAME = "^(c_|v_|h_|k_|i_|n_|aa_|nt_|va_|cur_|rec_)"

Usage of RegEx is beneficial in that it would afford maximum customization flexibility for validation of a variety of custom coding standards.

Backward compatibility: Implement a new Boolean setting; USE_TRIVADIS_DEFAULTS and replace the Trivadis default values with corresponding RegEx strings.

Instead of using Prefix.StartsWith(…) or Suffix.EndsWith(…), extract the corresponding value from the identifier and apply a RegEx matcher using the setting value of the identifier's context usage.

New behavior: if a setting is empty, skip validation for that identifier type. There are no defaults when USE_TRIVADIS_DEFAULTS = false.

Additional settings are requested -
PREFIX_COLLECTION_NAME
SUFFIX_PARAMETER_NAME
PREFIX_NON_CURSOR_PARAMETER_NAME

[PhilippSalvisberg]

Thank you for your enhancement request.

It's a good idea to use regular expressions to check the naming conventions of objects. However, instead of defining regular expressions for prefixes and suffixes, I think it might be more flexible and easier to define a regex per type. For example one regular expression for

• local variables
• input parameters
• output parameters
• input/output parameters
• etc.

In this case, I would not care about backward compatibility. The default would match the Trivadis guidelines and can be amended through configuration for others.

This will also have an impact on the guideline titles and texts. Even the numbering might be affected since there is no need for a dedicated guideline for the prefix and suffix of a type (record type and array type).

[PhilippSalvisberg]

related to DevOps ticket 65421.

[PhilippSalvisberg]

closed via f5e2f77