Naming conventions
Note
This is an ongoing document. It may include more content in future iterations.
Warning
Naming conventions must be applied without exception.
General rules
This section contains general rules applicable to all naming conventions.
Write names in English.
Use words that describe the name in a clear, concise and specific manner.
Avoid lengthy names.
If the name includes an action, use infinitive verbs followed by the object of the action.
Describe the entity or content entity only and avoid referencing other entities.
Naming classified by categories
Naming conventions are defined by category. Each category has a specific convention, with certain exceptions. The categories include:
App/Module
Entities (within apps or modules)
Entities content
App & Module
All names must be written following these rules:
Follow PascalCase capitalization rule: all words start with capital letters.
Separate words using underscores(_).
Entities
All names must be written following this rules:
Use snake_case: all words written in lowercase letters and divide words using underscores.
The chart below describes the entities in the Veritran platform. Learn how to define their names and see examples.
Assets | The name is defined by the category of the asset. It must include the category abbreviation and its identification. For example:
|
Branches | Release branches: Add a clear name. It must include the version number to be delivered, the delivery month, or any alias defined with the client. For example:
Feature and hotfix branches: Add a clear name. It must include the JIRA ticket linked to the feature implemented and a short descriptive name. For example:
|
Configurable component (created through component-type interface) | The name is defined by the configurable component type and their purpose. For example:
|
Functional flow (created through screen-type interface) | The name is defined by the functionality represented by the flow. For example:
|
Lambda process | The name is defined by the purpose of the process. For example:
|
Merge Request | The name or title is defined by the type of change (feature, fix, etc.), the name of the functionality and, if applicable, the ticket number. For example:
|
Screen | The name is defined by the purpose of the screen.
|
Sequence (in screen) | The name contains the letter S followed by the screen name.
|
Theme | The name contains the project name. It can also include any specific characteristic related to the theme. For example:
|
Transaction | The name is defined by the purpose of the transaction. For example:
|
Entities Content
All names must be written following these rules:
Use camelCase: The first word starts with a lowercase letter and the rest of the words are capitalized with no spaces.
Words must not be separated with any characters.
The chart below describes the content of entities in the Veritran platform. Learn how to define their names and see examples.
Lambda process variable | The name is defined by the content, not the variable type. It must include data structure context and, if applicable, include units. For example:
|
Lambda process function | The name is defined by the goal of the function or the operation it executes, represented by an infinitive verb. For example:
|
Lambda process function parameter | Parameters allow information to be passed to functions. The name is defined by the logic executed by the parameter. It must start with the letter p in lowercase letter, to differentiate it from a variable. For example:
|
Native component name ID | The name is defined by the purpose of the component. It must start the component abbreviation. For example:
|
Native component ID | ImportantNative component Name and ID must be the same. The name is defined by the purpose of the component. It must start the component abbreviation. For example:
|
Input parameter in module interface | For example:
|
Output parameter in module interface | For example:
|
Input value in transaction | |
Output value in transaction | |
Data (registers & alias) |