# Good practices | Rule | Rule description | | -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Language |

If there are no top-down decisions regarding the names of tasks, subprocesses, events, and gateways, we use Polish.
Name variables according to the convention adopted in the given application (in Polish or English).

| | Capitalization |

Start names with a capital letter, and write subsequent words in lowercase (e.g., "Document checking").
Exceptions include proper names and acronyms. Inconsistency (e.g., using lowercase once and uppercase another time) will make it harder to quickly recognize process elements.

| | Avoiding technical terms |

Instead of using classes or methods from the code, use business-friendly language.
Unclear or overly technical names can be misleading, e.g., instead of "Verify documents" using "ExecuteDocumentCheck" makes the process harder to understand for non-technical people.

| | Consistency of verbs in activity names | Use a consistent verb form in activity names in the process. For example, choose between infinitives ("Approve documents") and personal forms ("Approving documents") and use them consistently throughout the model. | | Precision and unambiguity | Make sure the name accurately reflects the given part of the process in a business context. Avoid ambiguous names that may be interpreted differently by different people. For example, instead of "*Handling the request*" it is better to use "*Recording a transaction complaint*". | | | Use unambiguous gateway descriptions, e.g. *"Yes"* / *"No"*. Avoid long, unnecessary descriptions and the use of technical terms such as *"True"* / *"False"*. | | | If possible, use more precise names for the start and end elements of the process than *"Start"* and *"End"* (they do not indicate the circumstances of the process starting or ending). | | Version numbering of process steps | If the process contains steps with similar names, add version or step numbering, e.g. "*Document verification 1*" and "*Document verification 2*", to avoid mistakes. However, try to avoid such names whenever possible (see rule above). | | Avoiding abbreviations | Avoid abbreviations, e.g. instead of using the abbreviation "*Cont. contract*", it is better to write the full form "*Contract approval*". | | Status names | If possible, use a single standard for status names (businessStatus) that takes the business context into account. | More information: