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.

DEMO_REPO folder

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:

Variables 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.

Schema example with named variables

The resulting variable list on exit is shown below. Here you can notice that the “TEMP_COUNTER” variable is missing.

Result, after deleting the TEMP_COUNTER

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.

File Reader rule

File Reader rule propes

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.

usage of the variable DAYS_IN_WEEK

Set Variable rule props

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:”.

DEMO_REPO repository details