MENU
    Best Practices for Naming Elements in Tulip
    • 30 Sep 2022
    • 4 Minutes to read
    • Contributors

    Best Practices for Naming Elements in Tulip


    Article summary

    Purpose

    Review our best practices for naming custom elements in Tulip as a starting point for your own apps and naming conventions.

    All custom named elements, e.g. Variables, Steps, Records, 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
    ExampleIssueBetter Example
    DoneNon-descriptiveOperation Finished
    operatorNameLowercase and no spaceOperator 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
    ExampleIssueBetter Example
    Total wgtAbbreviation and units.For regulated industries, see comment below.Total Weight (g)
    fltTemperatureFType in name, no space and wrong unitFor regulated industries, see next subsectionTemperature (°F)

    Regulated industries

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

    ExampleIssueBetter Example
    Temperature (°F)Only one variable used for value and unit of measureTemperature 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.

    ExampleIssueBetter Example
    Status FilterSuffix withoutFilter_Status
    IPCtimestamp FilterSuffix vs. prefix
    Lowercase and no spaceFilter_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.

    ExampleIssueBetter Example
    CPP TemperaturePrefix not clearly separated from variable nameCPP_Temperature (°C)
    AssayB_CQAUse as suffix vs. prefixCQA_Assay B
    AvailabilityMissing prefix for key indicatorKPI_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.

    ExampleIssueBetter Example
    Printed lables_tableUse of suffix#Printed Labels
    *Printed_labelsUse 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.

    ExampleIssueBetter Name
    Unnamed TriggerDefault nameIncrement defect counter
    Check statusToo little contextCheck order delivery status

    Was this article helpful?