Main Content

Identifier Format Control

You can customize generated identifiers by specifying the Identifier format control parameters on the Code Generation > Identifiers pane in the Configuration Parameters dialog box. For each parameter, you can enter a macro that specifies whether, and in what order, certain text is included within generated identifiers. For example, you can specify that the root model name be inserted into each identifier using the $R token.

The macro can include:

  • Valid tokens, which are listed in Identifier Format Tokens. You can use or omit tokens depending on what you want to include in the identifier name. The Shared utilities identifier format parameter requires you to specify the checksum token, $C. The other parameters require the mangling token, $M. For more information, see Avoid Identifier Naming Collisions. The mangling token is subject to the use and ordering restrictions noted in Identifier Format Control Parameter Values.

  • Token decorators, which are listed in Control Case by Using Token Decorators. You can use token decorators to control the case of generated identifiers for each token.

  • Valid C or C++ language identifier characters (a-z, A-Z, _ , 0-9).

The build process generates each identifier by expanding tokens and inserting the resultant text into the identifier. The tokens are expanded in the order listed in Identifier Format Tokens. Groups of characters are inserted in the positions that you specify around tokens directly into the identifier. Contiguous token expansions are separated by the underscore (_) character.

Identifier Format Tokens

TokenDescription
$C

This token is required for Shared utilities identifier format. If the identifier exceeds the Maximum identifier length, the code generator inserts an 8-character checksum to avoid naming collisions. For shared utilities that you generate from a MATLAB Function block, the code generator replaces the $C token with a checksum regardless of the length of the identifier. The position of the $C token in the Identifier format control parameter specification determines the position of the checksum in the generated identifier. For example, if you use the specification $N$C, the checksum is appended to the end of the identifier. This token is available only for shared utilities.

$M

This token is required. If necessary, the code generator inserts name-mangling text to avoid naming collisions. Modify checksum character length by using Shared checksum length parameter. The position of the $M token in the Identifier format control parameter specification determines the position of the name-mangling text in the generated identifier. For example, if you use the specification $R$N$M, the name-mangling text is appended (if required) to the end of the identifier. For more information, see Avoid Identifier Naming Collisions.

$U

Insert text that you specify for the $U token. Use the Custom token text parameter to specify this text.

$F

Insert method name (for example, _Update for update method). This token is available only for subsystem methods.

$N

Insert name of object (block, signal or signal object, state, parameter, shared utility function or parameter object) for which the identifier is being generated. For a list of resolutions for the $N token, see $N Embedded Coder Dictionary Resolution.

$R

Insert root model name into identifier, replacing unsupported characters with the underscore (_) character. When you use referenced models, this token is required in addition to $M (see Avoid Identifier Naming Collisions Between Referenced Models).

Note: This token replaces the Prefix model name to global identifiers option in previous releases.

$H

Insert tag indicating system hierarchy level. For root-level blocks, the tag is the text root_. For blocks at the subsystem level, the tag is of the form sN_. N is a unique system number assigned by the Simulink® software. This token is available only for subsystem methods and field names of global types.

Note: This token replaces the Include System Hierarchy Number in Identifiers option in previous releases.

$A

Insert data type acronym (for example, i32 for integers) to signal and work vector identifiers. This token is available for local block output variables, local temporary variables, and field names of global types.

Note: This token replaces the Include data type acronym in identifier option in previous releases.

$I
  • Insert u if the argument is an input.

  • Insert y if the argument is an output.

  • Insert uy if the argument is an input and output.

For example, rtu_ for an input argument, rty_ for an output argument, and rtuy_ for an input and output argument. This token is available only for subsystem method arguments.

$G

For data items, insert the name of a storage class that is associated with the data item. This token is also available in the naming rule that you specify for the Header File for a storage class in the Embedded Coder® Dictionary.

For service interfaces, insert the name of the service.

$E

Insert the file type. $E represents these instances of file types:

  • capi

  • capi_host

  • dt

  • testinterface

  • private

  • types

This token is required for Header files and Source files.

$X

This token applies only to sender, receiver, data transfer, and timer service function naming rules. Insert the name of the entry-point callable function that encloses the service function call.

Identifier Format Control Parameter Values lists the default macro value, the supported tokens, and the applicable restrictions for each Identifier format control parameter.

Identifier Format Control Parameter Values

ParameterDefault ValueSupported TokensRestrictions
Global variables$R$N$M$M, $R,$N,$U$F, $H, $A, $E, $I, and $G are not allowed.
Global types$N$R$M_T$M, $R,$N,$U$F, $H, $A, $E, $I, and $G are not allowed.
Field name of global types$N$M$M, $N, $H, $A, $U$R, $F, $G, $E, and $I are not allowed.
Subsystem methods$R$N$M$F$M, $R, $N, $H, $F, $U$F and $H are empty for Stateflow® functions; $A, $G, $E, and $I are not allowed.
Subsystem method argumentsrt$I$N$M $M, $N, $I, $U$R, $F, $H, $G, $E, and $A are not allowed.
Local temporary variables$N$M$M, $R, $N, $A, $U$F, $H, $G, $E, and $I are not allowed.
Local block output variablesrtb_$N$M$M, $N, $A, $U$R, $F, $H, $G, $E, and $I are not allowed.
Constant macros$R$N$M$M, $R, $N, $U$F, $H, $A, $G, $E, and $I are not allowed.
Shared utilities identifier format$N$C$N, $C, $R, $U$C is required. $M, $F, $H, $A, $G, $E, and $I are not allowed.
EMX array utility functions identifier format
emx$M$N$M, $N,$R$C, $U, $F, $H, $A, $G, $E, and $I are not allowed.
EMX array types identifier format
emxArray_$M$N$M, $N,$R $C, $U, $F, $H, $A, $G, $E, and $I are not allowed.
Header files$R$E$R,$U,$E $C, $M, $N, $F, $H, $A, $G, and $I are not allowed.
Source files$R$E$R,$U,$E $C, $M, $N, $F, $H, $A, $G, and $I are not allowed.
Data files$R_data$R,$U $C, $M, $N, $F, $H, $A, $G, $E, and $I are not allowed.

Non-ERT-based targets (such as the GRT target) implicitly use a default $R$N$M specification. This default specification consists of the root model name, followed by the name of the generating object (signal, parameter, state, and so on), followed by name-mangling text.

For limitations that apply to Identifier format control parameters, see Exceptions to Identifier Formatting Conventions and Identifier Format Control Parameters Limitations.

$N Embedded Coder Dictionary Resolution

The $N token resolves to the name of the object for which an identifier is being generated. The object type varies by the context of the naming rule. This table lists the objects to which $N resolves for items in the Embedded Coder Dictionary.

CategoryService InterfaceCustomization EntityDefault Naming RuleResolution of $N
ExecutionInitialize and Terminate FunctionsFunction Naming Rule$R$Ninit for Initialize Function blocks, term for Terminate Function blocks
Periodic and Aperiodic FunctionsFunction Naming Rule$R$Nreset for periodic functions, step for aperiodic functions
Service InterfacesReceiverFunction Naming Ruleget_$X$NInport block name
SenderFunction Naming Rule for Valueset_$X$NOutport block name
Function Naming Rule for Reference 
Data TransferReceiver Function Naming Ruleget_$X$N Data transfer signal name, such as DataTransferAt<Block><Outport><PortNumber>
Sender Function Naming Ruleset_$X$N
FunctionsFunction Customization TemplateHeader File Name of the function
Definition File
Internal FunctionsSubcomponent FunctionsFunction Naming Rule$R$NAssociated function element, such as the name of the port for an exported function
Shared Utility FunctionsFunction Naming Rule$N$CName of the function
MemoryStorage ClassHeader File$N.hModel or subsystem with which the data is associated
Definition File$N.cModel or subsystem with which the data is associated
Type Name$R$$N$G$MModel or subsystem with which the data is associated
Instance Name$G$N$MModel or subsystem with which the data is associated
Name of Getterget_$N$MAssociated data element
Name of Setterset_$N$MAssociated data element

Control Case by Using Token Decorators

On the Code Generation > Identifiers pane, you can use token decorators to control the case of generated identifiers. Place a decorator immediately after the target token and enclose the decorator in square brackets [ ]. For example, you can set Global variables to $R[uL]$N$M, which capitalizes the first letter of the model name and forces the remaining characters in the model name to lowercase.

The table shows how to manipulate the expansion of the $R token for a model whose name is modelName.

Desired ExpansionDescriptionToken and Decorator
ModelNameFirst letter of model name is uppercase. Remaining characters are not modified.$R[u]
ModelnameFirst letter of model name is uppercase. Remaining characters are lowercase.$R[uL]
MODELNAMEAll characters are uppercase.$R[U]
modelnameAll characters are lowercase.$R[L]
mODELNAMEFirst letter of model name is lowercase. Remaining characters are uppercase.$R[lU]
modelNameFirst letter of model name is lowercase. Remaining characters are not modified.$R[l]

When you use a decorator, the code generator removes the underscore character (_) that appears between tokens by default. However, you can append each decorator with an underscore: $R[U_]$N. For example, if you set the Global variables parameter to $R[u_]$N[uL]$M for a model named modelName and a DWork structure represented by DW, the result is ModelName_Dw.

Modify Identifiers by Using Regular Expression Decorators

To modify identifiers in ways other than by case, you can use regular expressions. To use a regular expression, enclose the decorator in double quotes. A regular expression decorator contains two regular expressions separated by a forward slash. The code generator searches for substrings of the token that match the first regular expression and replaces those substrings using the second regular expression. For example, the following identifier naming rule takes the root model name $R and replaces instances of a with b: $R["a/b"]. The code generator interprets regular expression syntax in a way that is consistent with the regexprep function, except regular expression decorators do not support dynamic expressions, which use MATLAB® commands.

You can configure a regular expression decorator by appending a list of options to the end of the decorator. Separate the options from the second regular expression by using a forward slash and separate the options from each other by using the pipe character. For example, the following identifier naming rule takes the root model name $R and replaces only the first instance of a with b, ignoring case: $R["a/b/once|ignorecase"].

CategoryOptionDescriptionExample DecoratorExample InputExample Output
Match/replace occurrenceall (default)Match and replace the expression as many times as possible.
["a/-/all"]
afabcswbc-f-bcswbc
onceMatch and replace the expression only once.
["a/-/once"]
afabcswbc-fabcswbc
NWhere N is an integer, match and replace the Nth occurrence of a match.
["a/-/2"]
afabcswbcaf-bcswbc
Case matchingmatchcase (default)Match letter case.
["aBcD/wXyZ/matchcase"]
abcdABCDabcdABCD
ignorecaseIgnore letter case.
["aBcD/wXyZ/ignorecase"]
abcdABCDwXyZwXyZ
preservecaseIgnore letter case while matching but preserve the case of corresponding characters in the original text while replacing.
["aBcD/wXyZ/preservecase"]
abcdABCDwxyzWXYZ
Empty matchingnoemptymatch (default)Ignore zero-length matches.
["^/prefix/noemptymatch"]
abcdABCDabcdABCD
emptymatchInclude zero-length matches.
["^/prefix/emptymatch"]
abcdABCDprefixabcdABCD

If a regular expression decorator results in uncompilable code, the code generator produces an error before building the code.

Regular Expression Limitations

  • Regular expression decorators are applicable only to $G, $N, and $R tokens.

  • Unlike regexprep, regular expression decorators do not support dynamic expressions, which use MATLAB commands.

  • Regular expression decorators are not supported for function mappings in the Code Mappings editor.

  • The code generator cannot evaluate whether a regular expression is valid. An invalid regular expression does not result in a change to the affected token and does not produce a warning.

Control Formatting of Identifiers

This example shows how to customize generated identifiers by specifying the Identifier format control parameters on the Code Generation > Identifiers pane in the Configuration Parameters dialog box. To maintain model traceability, incremental revisions to a model must have minimal impact on the identifier names that appear in the generated code. This example shows how to minimally impact the identifier names by specifying the Identifier format control parameters.

Inspect Model

Open the IdentifierFormatting model.

model = 'IdentifierFormatting';
open_system(model)

The model contains two subsystems, multiply_by_2 and multiply_by_4, and a Stateflow® Chart, determine_if_positive. Each subsystem contains a Gain block.

Inspect Model Configuration Parameters

Open the model configuration parameters dialog by selecting Model Settings on the Modeling tab. On the left pane, select Code Generation > Identifiers.

Inspect the Subsystem methods parameter. By default, this parameter has the value $R$N$M$F. The $R token expands to the model name, IdentifierFormatting. The $N token expands to the name of the Simulink object that corresponds to the identifier, such as multiply_by_4. If you generate separate output and update methods for subsystems, the $F token expands to _Update or _Output for each generated method.

After expanding these tokens, if the code generator generates multiple identifiers with the same name, it expands the $M token to name-mangling text to prevent naming collisions.

Generate Subsystem Method Identifiers Without $N

Remove the $N token from the Subsystem methods parameter.

Generate the code. The generated code includes these functions for the subsystems in the model:

static void IdentifierFormatting_c(void);
static void IdentifierFormatting_a(void);

Because the model is not configured to generate separate output and update subsystem methods, the $F token does not expand. The $R token expands to the root model name IdentifierFormatting. Both the multiply_by_2 and multiply_by_4 subsystems generate the IdentifierFormatting function name, which causes an identifier naming collision. To resolve the collision, the code generator expands the $M token to a single character of name-mangling text in each identifier name: c in the first function and a in the second function.

Generate Subsystem Method Identifiers with $N

Restore the Subsystem methods configuration parameter to the default value of $R$N$M$F.

Generate the code. The generated code includes these functions for the subsystems in the model:

static void IdentifierFormatting_multiply_by_2(void);
static void IdentifierFormatting_multiply_by_4(void);

Because the $N token expands to a unique value for each subsystem, the code generator does not generate name-mangling text.