Naming Conventions
Consistent Naming Scheme
Names should have word boundaries. There are two popular options:
camelCase (first letter of each word is capitalized, except the first word)
and underscores between words (like “user_surname”).
The underscore naming scheme in combination with the camelCase scheme is proposed for rule set names, as it can easily depict hierarchical structures, as shown below.
Repository names tend to be more humanly readable and are space separated words (“Rule Wizard”, “Silly Selfies”, “Notepad Demo”). But consistency is always important, no matter what naming scheme is used.
Variable Names
Give readable variable names that are easily distinguishable in a variable listing and are helpful for debugging.
Variable names should also be independent of platform or environment, e.g. CUSTOMER_NAME and not DEV_CUSTOMER_NAME.
Capital letters with underscore-separated words are proposed for the Tomorrow Software environment. Below is a variable list example:
Temporary Variable Names
Temporary variables with the same prefix could all be deleted with the “Delete Selected Variables” rule which could be called before the rule set exit. This is a proposed practice, as it cleans up the variable list, which makes it easier for debugging.
Below is an example of setting the variable “TEMP_COUNTER” and later deleting it before exit.
The resulting variable list on exit is shown below. Here you can notice that the “TEMP_COUNTER” variable is missing.
File Names
Variable values or parameter values that are file names should be case-sensitive.
In the below example the file’s name is “index.html” and therefore the parameter “File Name” should have the exact same case-sensitive value.
Unnamed numerical constants
Avoid using unnamed numerical constants, as to make clear what the number is supposed to represent, and to accommodate future changes. Its value can be set into a variable, and then the variable can be used wherever needed.
In the future if a change needs to be made to this value, it can easily be made once only in the “Set Variable” rule.
In the example below the variable “DAYS_IN_WEEK” is assigned the value “7” instead of using the number “7” directly in the “Counting loop” rule.
Avoid conflicts in rule set names among repositories
Rule sets that are exported from the repository should have unique names so that there are no clashes with other rule sets in the repositories in which they are included.
Below is an example of the repository “User Agent Detection” being included into the DEMO_REPO repository, under the label “Include data, content and rule sets from:”.
Last updated
