Filenames:
All filenames will start with "hu." The rest of the name will be either the name of the class (without the "HU," see below) contained within the file, or if there are multiple classes, the most obvious name to give the file (either the most important class, or a name of the group of classes). The extension of the filename will either be ".H" or ".C"
Thus, the name of the header file containing the class HUEvent would be "huEvent.H"
Classnames:
All classnames will begin with "HU". All separate words of a class name will have the first letter capitalized, and there is no underscore between words. Thus, the code generator class name will be "HUCodeGenerator."
Instance Variables:
All instance variables will have an underscore before the name, and no other underscore within the name. The first letter will always be in lower case, but all other words in the variable will be capitalized (such as _myInstanceVariable). The instance variables should be descriptive (but try not to make them too long). There should be no public instance variables in any class. Instance variables will be declared below all class functions.
Local Variables:
Local variables should have no initial underscore. They do not have to be defined at the beginning of the function. They should be defined where it makes most sense in terms of code readability.
Constants:
Constants should be in all capital letters, and words should be spaced by underscore.
Functions:
Functions will follow the same naming convention as instance variables, but without the leading underscore. See Header File Format below for more function coding conventions.
Header File Format:
All public functions should be declared first in the header file, then protected, then private. All similar functions should be grouped together (like accessor functions, etc.)
Forward class declaration should be used as much as possible. The heap should be always used in favor of the stack. One should pass by pointer instead of by reference, unless the type is a base type and the function would be simplified if references were used.
Commenting:
We suggest the use of stubgen to generate .C files, although it is not required. However, all non-intuitive functions should have a description (placed before the function code in the .C file) of what the function does, what parameters it expects (and the expected values), what it returns, how the function handles errors, and any other important.
Commenting will be done as you code. Do not code and then come back to it a few days later and comment. Comments should be ubiquitous, but not so much that it makes the code unreadable. It is up to your best judgement where to put comments. A good guideline is to put comments before all for loops, non-obvious if statements and any line of code which is substantial and non-intuitive.
If you are editing someone else's code or code that is not obviously your own, all changes should be initialized so that we can figure out who edited what in case we have a question.
Debugging/Testing:
Refer to the Final Design Document under Module Testing and Integration Testing for how to write testing and debugging code.
Other Errata:
Make your code neat! Obviously, use indention
Avoid typedefs, with the possible exception of typedefing templates and STL lists. Also, Reiss's Info* is forever banned from this project.
Make your code neat.
Emacs and vi should be set up so that indention is identical between each other. Perhaps Chris could do this?
Speaking of Chris, he will set up the directories since he is setting up CVS.
Make your code neat.