All custom named elements, e.g. variables, steps, record, etc., in Tulip should be named in a way that makes them human readable, unambiguous, and understandable to facilitate usability of apps during their life cycle.

It is recommended to adopt the following general naming conventions for all elements:

  • Descriptive name
  • Words written out in full, no abbreviations
  • First letter of each word in upper case, subsequent letters in lower case
  • Individual words separated by a space

Example

Issue

Better Example

Done

Non-descriptive

Operation Finished

operatorName

Lowercase and no space

Operator Name

The sections below outline some more detailed guidelines for specific elements.


Variables

Variable names must be unique with an App, however the same names can be reused within the Tulip platform.

  • Variable type not included in name
  • Unit abbreviations written in parenthesis next to name of numeric variables

Example

Issue

Better Example

Total wgt

Abbreviation and units.

For regulated industries, see comment below.

Total Weight (g)

fltTemperatureF

Type in name, no space and wrong unit

For regulated industries, see next subsection

Temperature (°F)

Regulated industries

It is recommended to store a value and its unit of measure in two separate variables/table fields, e.g. “Total Weight” and “Total Weight_UOM”. See GxP App Building Best Practices for more information.

Example

Issue

Better Example

Temperature (°F)

Only one variable used for value and unit of measure

Temperature

Temperature_UOM

Variables used to filter tables

Variables used to filter a table with respect to a specific column should be named with the prefix ‘Filter’. This improves the usability of those variables during app building. This is recommended for variables solely used for filtering. General purpose variables in Apps do not need a prefix.

Example

Issue

Better Example

Status Filter

Suffix without

Filter_Status

IPCtimestamp Filter

Suffix vs. prefix

Lowercase and no space

Filter_IPC Timestamp

Variables for key indicators

For Apps with key indicators, e.g. CPPs/CQAs (Critical Process Parameters / Critical Process Attributes) or KPIs, add a prefix to the variables’ names to improve the readability of the variables.

Example

Issue

Better Example

CPP Temperature

Prefix not clearly separated from variable name

CPP_Temperature (°C)

AssayB_CQA

Use as suffix vs. prefix

CQA_Assay B

Availability

Missing prefix for key indicator

KPI_Availability


Tables

Tables names should adapt the same naming convention used for variables and be grouped with a prefix. Tables should be grouped against general purpose, e.g. multiple/all use cases, or specific use cases. It is recommended to use ‘#’ for general purpose grouping and not to use ‘*’. The ‘*’ is used by Tulip to mark tables originating from Tulip library Apps.

Example

Issue

Better Example

Printed lables_table

Use of suffix

#Printed Labels

*Printed_labels

Use of ‘*’ prefix

#Printed Labels


Triggers

It is not recommended to use the default “unnamed trigger” name. Instead, the name of a trigger should describe its functionality in a few words.

Example

Issue

Better Example

Unnamed Trigger

Default name

Increment defect counter

Check status

Too little context

Check order delivery status

Did this answer your question?