When editing code, the following guide should be followed.

• Use the existing code as your guide. Always ask yourself, "is this pretty, can I make it better, is there another way to organize this?"" - Use "camelCase" for variables and functions. - The pointer to the <tt>domn</tt> object is the primary communicator that allows passage of information between classes and functions. Avoid declaring global variables or passing values through function parameter lists unnecessarily. - Be minimally invasive to the code. Inherit from existing classes and use oaverloading. Do not clutter the code with <tt>if</tt> clauses. - The flamelet code (described below) is an example of inheriting off key classes. - For example, a <tt>stats</tt> class should be added. Calls to this class could be made using a single line of code. If stats is not active it would simply return. If it is active, the called function alone determines what to do. It would have nearly full access to the rest of the code through the <tt>domn</tt> pointer. A function argument could indicate the appropriate action to take that is specific to the <tt>stats</tt> class. This avoids <tt>if</tt> statements and preprocessor directives. - Code should be self explanatory. Use descriptive but succinct variable names. For example <tt>dv</tt> is used in the code instead of <tt>domainVariable</tt>. Also <tt>d</tt> is used instead of <tt>data</tt>. While in each case, the latter is more descriptive, a simpler name was used due to the frequency of use. Conversely, lesser-used variables, such as <tt>domainLength</tt> are used for clarity. - Avoid preprocessor directives. They seriously clutter the code. - Modular code is good: avoid monolithic blocks of code; fit a function on one page if possible. - Header files should be short and consice. Do not put function definitions in header files (unless they are one line long). Code goes in the code files. - In header files, separate the data members from the member functions from the constructors and destructors. They should go in that order. - Use English throughout. - Boolean flags are usually prepended with an upper case "L" to indicate a "logical" variable. - Use comments liberally. Comments to the right of code are preferred. - Use double slash comments everywhere except in class and function definitions. - Document the code using Doxygen-style directives. All variables declared in header files should have Doxygen-style comments. See the header files for examples of this. Also, document functions and classes. Include parameter definitions and whether they are inputs or outputs. Also give return values. - Line up the code and comments vertically. Groups of similar statements should have aligned equal signs, and aligned comments. - Use blank lines liberally to help group and separate code sections. - Use indentation with 4 spaces (not 2). - No tabs allowed. Use text editors that insert 4 spaces when the tab key is pressed. - Avoid inserting trailing whitespace at the end of a line. - Put the initial opening curly brace of code blocks on the same line. Put the closing curly brace of code blocks on their own line. - Most class members are public on purpose. Lets keep it that way. Private variables can be useful for self-documenting that they are only ever needed in the given class, but we are not trying to "hide" variables in this code.