Naming Conventions

This section describes the naming conventions we will use. The purpose of these naming conventions is to make it easier for us to use each other's code. It will try to ensure some consistency between what we each write, and between what we write today and what we write next year. In general, names should be descriptive. There are almost no cases where abbreviations should be used in names a user of the code (other developer) would see. Mixtures of abbreviated and unabreviated names become hard to remember[[2]]. We may have a set of names that are always abbreviated, in which case they shouldn't be left unabreviated. These names will be in the file pris/doc/naming.txt. Names should also describe what the function or class does. If purpose of the function changes, the name should change too.

Free Functions Ri + Cap each word RiComputeSolution

Member Function Cap each word ComputeSolution

Typedefs Ri + Cap each word RiRadiance

Classes Ri + Cap each word RiRayObject

Variables, function/class Cap all but first word errorWeight

Variables, global ri + Cap each word riErrorWeight

Enumerated Type Values same as Variables riXCoord

Include Guards FILENAME + _H RISTACK_H

File Names Same as main class name RiStack.[HC]

Notes on the naming conventions.

Function Names

Make the names descriptive of what the function does. Often this means using verbs for the first word of the function name. GetValue, IsValid, FindObject.

Global Variables

These should primarily be used as constants (static by default). If they are not constants, then they must be static and they should be made thread safe.

Enumerated Types

These should be declared within classes whenever possible. In these cases they don't need the Ri prefix for the type or the ri prefix for the values.

Include Guards

It actually is important to follow this naming convention as we may have extra include guards at the location where the .H file is included to speed up compilation [[1]].