MISRA C++:2023 Rule 5.10.1

User-defined identifiers shall have an appropriate form

Since R2024b

Description

Rule Definition

User-defined identifiers shall have an appropriate form.

Rationale

This rule restricts the names that can be given to user-identifier identifiers.

The restrictions reduce possible ambiguity and improve the portability of your code by:

• Supporting only Unicode-recommended characters in identifier names.

• Preventing collisions with reserved names.

• Allowing clear distinction between identifiers and macros.

• Enforcing some commonly-accepted coding styles.

Polyspace Implementation

Following the MISRA™: C++: 2023 specifications, the rule checker reports a violation if an identifier uses a forbidden name, as defined below.

Type of Identifier	Forbidden Names
All types, except macros.	Names that start with a universal character outside [a-z], [A-Z], or _, or outside the character class XID_Start. Names that contain a universal character outside [a-z], [A-Z], or _, or outside the character class XID_Continue. Names that do not conform to Normalization Form C (NFC). Names that contain a double underscore. Names that are reserved keywords in most typical contexts, for instance, size_t, ptrdiff_t, va_list, etc. Names that start with _ (except user-defined literal suffix – see later).
Macros	Names that contain a character outside [A-Z] or _
Namespaces	The names std, posix or stdN, where N is a number.
User-defined literal suffix	Names that do not start with _ or contain a space before the starting _.

Troubleshooting

If you expect a rule violation but Polyspace^® does not report it, see Diagnose Why Coding Standard Violations Do Not Appear as Expected.

Examples

Incorrect Names of User-defined Literal Suffixes

void operator ""_m( long double ); //Compliant 
void operator ""__km( long double ); //Noncompliant - Starts with a double underscore
void operator ""cm( long double ); //Noncompliant - Does not start with an underscore
void operator "" _mm( long double ); //Noncompliant - Contains a space before underscore

In this example, the user-defined literal suffix _m starts with an underscore without a preceding space and does not violate the rule. The other suffixes do not follow this convention, therefore violate the rule.

Check Information

Group: Lexical Conventions

Category: Required

Version History

Introduced in R2024b