Development guide

Names

All source code related to a specific Model-of-Computation must be placed in a unique namespace.

The above rule enforces a separation of the source code related to different Models-of-Computation through a namespace. This makes it possible to safely re-use variable names when developing code for different Models-of-Computation. Moreover, it forces a designer to make the use of functions from a different Model-of-Computation explicit. This increases the readability of the source code.

The names of variables, and functions begin with a lowercase letter.
The names of abstract data types, classes, structures, types, and enumerated types begin with an uppercase letter.

The above rules enforce a clear separation between variables and data types. This increases the readability of the code.

In names that consist of more than one word, the words are written together and each word that follows the first begins with an uppercase letter.
Underscores may not be used in the names.
Do not use type names that differ only by the use of uppercase and lowercase letters.
Names should be self-descriptive yet as brief as possible. Cryptic abbreviated names are as hard to read as well as too long ones.
Names should be pronounceable. It is hard to discuss something that cannot be pronounced.
Names should not include abbreviations that are not generally accepted.
Avoid encodings in names. Encoded names require deciphering. Especially, avoid type-encoded variable names (Petzold-style Hungarian notation like lpcszName).
Be consistent. If something is a name it should be a name everywhere it is used (it should for example not be used as an id somewhere else).