|
|
||
|
Name checks follow grammar checks in the sequence of most basic tests that are performed automatically for each newly defined operation in the interactive mode - again, this automatic check can be switched off with appropriate configuration option, which can be useful for batch processing.
The name check, when performed automatically and when successful, is reported together with the grammar check with a green confirmation message:
When the grammar check fails, the name check that should follow it is not attempted.
It is possible for the operation to have correct grammar, but fail some of the name checks - for example, when a local variable would hide the package-level object of the same name:
Above, even though the grammar is correct (and reported with green message), name checks failed, which is reported with the remaining part of the message displayed in red.
The same check for a single operation can be invoked explicitly with the following command:
In either case, the button “Show details” displays the report for two kinds of conflicts - package-level and operation-level ones:
Package-level conflicts are those that were identified outside of operation bodies, for example between type names and object names. In this case the are no such conflicts, so the only package in the model is marked with green “OK”. Below that, a detailed list for each operation, grouped by package, shows the names that are in conflict with other names - these, like the variable x above, are highlighted in red.
Name checks have their raw-report version as well:
This structure is a nested Association, keyed by package name, where values are pairs containing the list of conflicts at the package level and, bound in a single nested association object with operation names as keys, the list of conflicting names for each operation within that package. The above shows an empty list of package-level conflicts and a single element x in the list of conflicts for myOperation, all for a single package that was declared within this model.
In the case of this particular example, changing the local variable name fixes the problem:
Explicitly invoked checks confirms that as well, even for the whole model:
Name checks ensure that all names that are visible in any given context are unique - no name hiding is allowed.
An important note is that name checks that were once successful for the given operation might become failing as an unintended effect of model modifications applied outside of the operation body - for example, when a package-level data object or a type definition is added after the operation was defined, the operation will be “blamed” for new conflicts.
What makes name checks different from grammar checks, however, is that they do not necessarily impact the integrity of other checks and they do not prevent the generation of final source code. Still, it is not recommended to force the generation of code with such “soft” name conflicts - the generated code will most likely create downstream violations, for example by conflicting with coding standards like MISRA-C.
Previous: Grammar checks, next: Flow checks
See also Table of Contents.