Recommendations \ on the naming of identifiers

Identifiers are defined at the declaration of variables (variable names), user-defined data types and at the creation of POUs (functions, function blocks, programs) and visualizations. You might follow the following recommendations concerning the naming of identifiers in order to make it as unique as possible.

1. Variable names

The naming of variables in applications and libraries as far as possible should follow the Hungarian notation:

For each variable a meaningful, short description should be found, the base name. The first letter of each word of a base name should be a capital letter, the others should be small ones (Example: FileSize). If needed additionally an translation file for other languages can be created.

Before the base name, corresponding to the data type of the variable, prefix(es) are added in small letters.

Data type	Lower limit	Upper limit	Information content	Prefix	Comment
BOOL	FALSE	TRUE	1 Bit	x*
				b	reserved
BYTE			8 Bit	by	Bit string, not for arithm. operations
WORD			16 Bit	w	Bit string, not for arithm. operations
DWORD			32 Bit	dw	Bit string, not for arithm. operations
LWORD			64 Bit	lw	not for arithm. operations
SINT	-128	127	8 Bit	si
USINT	0	255	8 Bit	usi
INT	-32.768	32.767	16 Bit	i
UINT	0	65.535	16 Bit	ui
DINT	-2.147.483.648	2.147.483.647	32 Bit	di
UDINT	0	4.294.967.295	32 Bit	udi
LINT	-2:sup:63	2:sup:63 - 1	64 Bit	li
ULINT	0	2:sup:64 - 1	64 Bit	uli
REAL			32 Bit	r
LREAL			64 Bit	lr
STRING				s
TIME				tim
TIME_OF_DAY				tod
DATETIME				dt
DATE				date
ENUM			16 Bit	e
POINTER				p
ARRAY				a

* pointedly for  BOOLean variables x is chosen as prefix, in order to differentiate from BYTE and also in order to accommodate the perception of an IEC-programmer (see addressing %IX0.0).

Examples:

bySubIndex: BYTE;

sFileName: STRING;

udiCounter: UDINT;

In nested declarations the prefixes are attached to each other in the order of the declarations:

Example:

pabyTelegramData: POINTER TO ARRAY [0..7] OF BYTE;

Function block instances and variables of user-defined data types as a prefix get a shortcut for the FB- resp. data type name (Examle: sdo).

Example:

cansdoReceivedTelegram: CAN_SDOTelegram;

TYPE CAN_SDOTelegram :  (* prefix: sdo *)

STRUCT

wIndex:WORD;

bySubIndex:BYTE;

byLen:BYTE;

aby: ARRAY [0..3] OF BYTE;

END_STRUCT

END_TYPE

Locale contants (c) start with prefix c and an attached underscore, followed by the type prefix and the variable name.

Example:

VAR CONSTANT

c_uiSyncID: UINT := 16#80;

END_VAR

For Global variables (g) and Global constants (gc) an additional prefix + underscore is attached to the library prefix:

Examples:

VAR_GLOBAL

CAN_g_iTest: INT;

END_VAR

VAR_GLOBAL CONSTANT

CAN_gc_dwExample: DWORD;

END_VAR

2. User-defined data types (DUT)

The name of each structure data type consists of a library prefix (Example: CAN), an underscore and a preferably short expressive description (Example: SDOTelegram) of the structure. The associated prefix for used variables of this structure should follow directly after the colon.

Example:

TYPE CAN_SDOTelegram :   (* prefix: sdo *)

STRUCT

wIndex:WORD;

bySubIndex:BYTE;

byLen:BYTE;

abyData: ARRAY [0..3] OF BYTE;

END_STRUCT

END_TYPE

Enumerations start with the library prefix (Example: CAL), followed by an underscore and the identifier in capital letters..

Regard that in previous versions of CoDeSys ENUM values > 16#7FFF have caused errors, because they did not get converted automatically to INT values. For this reason ENUMs always should be defined with correct INT values.

Example:

TYPE CAL_Day :(

CAL_MONDAY,

CAL_TUESDAY,

CAL_WEDNESDAY,

CAL_THIRSDAY,

CAL_FRIDAY,

CAL_SATURDAY,

CAL_SUNDAY);

Declaration:

eToday: CAL_Day;

3. Functions, Function blocks, Programs (POU)

The names of functions, function blocks and programs consist of the library prefix (Example: CAN), an underscore and an expressive short name of the POU (Example: SendTelegram). Like with variables always the first letter of a word of the POU name should be a capital letter, the others should be small letters. It is recommended to compose the name of the POU of a verb and a substantive.

Example:

FUNCTION_BLOCK CAN_SendTelegram (* prefix: canst *)

In the declaration part a short description of the POU should be provided as a comment. Further on all inputs and outputs should be provided with comments. In case of function blocks the associated prefix for set-up instances should follow directly after the name.

Actions get no prefix; just actions which should be called only internally, i.e. by the POU itself, start with prv_.

Each function - for the reason of compatibility with previous CoDeSys versions - must have at least one parameter. External functions must not use structures as return values.

4. Identifiers for Visualizations

Note: Currently you must avoid that a visualization has the same name like another POU in the project. This would lead to problems in case of changes between visualizations.