To convey the key message across the document are organised as simple recommendations using Always, Endeavour, Consider, Avoid, Never. Each guideline is described as either good or bad practice. The following table illustrates the recommendation keywords and their intended meanings.
| Keyword | Meaning |
|---|---|
| Always | The guideline should always be followed. Example: Always use Pascal casing for enterprise service and operations names. |
| Endeavour | The guideline should be followed in most cases; however there are few edge cases where it makes sense not to follow the guideline or it is impractical to expect developers to follow the guideline all the time. Example: Endeavour to follow the defined messaging patterns - sync, async, pub/sub, guaranteed delivery, etc. |
| Consider | The developer should consider the guideline as an option for solving a particular problem. Example: Consider using machine generated code. |
| Avoid | The guideline indicates something that is not generally a good practice. In most cases; developers are expected to follow the guideline. Example: Avoid comments that explain the obvious. |
| Never | The guideline indicates something the developer should almost never do. Example: Never use hardcode environment variables. |
