5.2 Naming conventions

This topic describes the naming conventions that Iris APIs use.

Table 5-1 Naming conventions for Iris functions, objects, and events

Identifier Case Example
Function name lowerCamelCase instanceRegistry_registerInstance
Function argument name lowerCamelCase instId
Object member name lowerCamelCase bitWidth
Object type name UpperCamelCase RegisterInfo
- lowercase_with_underscores Not used.

Acronyms are treated like normal words and are written in lowercase, but sometimes have an uppercase first letter, for example isTcp, isCpp, isJson.

Function names

Function names are hierarchical, with hierarchy levels separated by an underscore. All functions have at least two parts, namely the group or interface name, and the function name, for example resource_read. Function names might have more hierarchy levels to further group the functionality.

See also 5.20.8 Naming conventions for new functions for the naming conventions to use when enhancing the interface.

Experimental functions

Experimental functions are prefixed by experimental_ to avoid namespace pollution. Experimental functions are not part of the official Iris interface. Their semantics, arguments, and return values can change without notice. Experimental functions might become part of the Iris interface, and then lose the prefix, or might be removed without replacement.

Custom functions

Custom functions are prefixed by custom_companyName to avoid name clashes when multiple companies extend the Iris interface with their own functions. Introducing custom functions must be avoided if possible. It is preferable to use a combination of registers, memory spaces, tables, and event sources instead.

Function argument names

Function argument names should be short, if possible less than 24 bytes long, so that function implementations can compare argument names with one or three uint64_t compares. Details about an argument can be put into a description string which is retrieved using instance_getFunctionInfo(), rather than in its name. However it is useful to indicate the units, for example bits, bytes, elements, or milliseconds, in the argument name if multiple interpretations are possible. For example, tickHz or bitWidth.

Object member names

Object member names, for example in return values or in complex arguments, should be less than 24 bytes long.

Non-ConfidentialPDF file icon PDF version101196_0100_03_en
Copyright © 2018, 2019 Arm Limited or its affiliates. All rights reserved.