Skip to main content

Naming Conventions

Consistent and clear naming conventions are crucial for building maintainable and scalable Mendix applications. They improve collaboration, enhance readability, and help enforce architectural principles, making it easier for new developers to understand the app's logic.

1. General Naming Principles​

  • Be Descriptive: Names should clearly describe the element's purpose and functionality.
  • Be Consistent: Use the same naming pattern throughout your entire application. This consistency makes it easier for everyone on the team to read and navigate the codebase.
  • Show the involved main entity/entities: For microflows, include the main entity they involve. This makes them easier to find and understand their context within the application's data model.
info

The conventions in this chapter are inspired by Menditect's naming conventions and are intended as a guide, not a strict rule book. As long as they adhere to these general principles, your own customer-specific conventions can be just as effective. The goal is clarity and consistency, which helps everyone work together more efficiently.

2. Deviation of Mendix naming Conventions​

The Mendix best practices on microflows states: “Generally, microflow names should include the type of event which triggers them”. However, this approach is not implemented in the Testability Framework. The naming convention of the Testability Framework is first naming the microflows after their purpose and sometimes add subtyping to clarify it’s triggering.

3. Microflow Naming Conventions​

The naming convention for microflows should reflect their purpose. This aligns directly with the concept of microflow typologies.

The following conventions describe an initial setup, but can be expanded based on the needs.

3.1. Naming conventions of touchpoint microflows​

The standard pattern is: {TYPOLOGY PREFIX}_{SUBTYPE PREFIX}_{touchpoint name}_{action}

  • {TYPOLOGY PREFIX}: Indicates the microflow typology.
  • {SUB-TYPOLOGY PREFIX}: Indicates the sub typology of the microflow
  • {touchpoint name}: the name of the touchpoint where the microflow belongs to
  • {action}: The specific action the microflow performs.

Examples:

  • ACT_order_newedit_save
  • ACT_DS_order_get_orderlines

3.2. Naming conventions of orchestration microflows​

The pattern is {TYPOLOGY PREFIX}_{main object name}_{action}

Examples:

  • ORC_order_process_subscription
  • ORC_email_send_notification

3.3. Naming conventions of unit microflows​

The pattern is {TYPOLOGY PREFIX}_{main object name / parameter name}_{action / check }

Examples:

  • FTN_email_format
  • GET_orderline_by_order
  • OPR_order_create
  • VAL_order_start_before_end
info

The main object of the getter microflow (GET) is the object that is returned.

3.4. Sub-typing microflows​

When sub-typing is applied, the sub-type is written in capitals and appended to the main type, separated by an underscore.

The following sub types are commonly used:

  • ACT_DS: to identify data source microflows for a large page.
  • ACT_EVT: to identify data source microflows that are triggered by a page event (i.e. on-leave).
  • ACT_ORC: to indicate shared page functionality that is specific to a page but doesn't belong in the more generic orchestration microflow (ORC).
  • ORC_CMT: to distinguish orchestration microflows that call a commit microflow (CMT) from those that don’t.
  • GET_M / GET_D: to separate unit microflows that retrieve data by association (from memory) (M) from those that retrieve data directly from the database (D).

4. Page Naming Conventions​

Pages should be named for clarity and context, often indicating their purpose within a workflow.

The standard pattern is {Main page entity}_{Operation or Context}

Examples are: Customer_Overview, Order_NewEdit, Dashboard_Main

5. Entity Naming Conventions​

Entities should be named as singular nouns in UpperCamelCase. They should represent real-world objects in your domain model.

Examples are: Customer, OrderLine, Product

Within Menditect, Entities are given a four letter code. Like ORDR_Order. This four letter code is used in microflow naming conventions, variable names, microflow parameters etc. For example GET_D_customer_by_order is named GET_D_ctmr_by_ordr.

A minor drawback seems to be that you have to remember the entity codes. In practice, however, you see the entity type of a parameter or variable everywhere in Mendix Studio Pro, so remembering it is almost never a problem. The big advantage of this convention is that it significantly reduces the length of microflow names and makes it easier to find microflows for reuse by just typing the code.

image-20251211-141751.png

7 Attribute Naming Conventions​

Attributes follow the Mendix naming conventions.

8 Naming Conventions for Variables and Parameters​

Variables and parameters could use camelCase and be as descriptive as possible. Exact convention depends on the type of the variable or parameter:

  • Entity:
    • Full entity name, start with a capital (Order).
    • If four-letter entity codes are adopted, only the four lettercode is used (ORDR)
  • Entity list:
    • Full entity name, start with a capital ending with the postfix ‘_list’ (Order_list).
    • If four-letter entity codes are adopted, the four letter code is postfixed with an 's' (ORDRs)
  • Attribute:
    • Full entity name postfixed with the attribute name (orderStartdate)
    • If four-letter codes are adopted, the four letter code is postfixed with the attribute name (ordrStartdate)
  • Primitives
    • CamelCase, start with lowercase (isValid).