CS 311 Fall 2009
Coding Standards

The following standards must be followed on all source code (including header files) turned in as CS 311 assignments. First and foremost is the following standard.

• All code turned in must compile and execute. If a test program is provided, then the code must compile with the unmodified test program. Code that does not meet this standard will not be graded.

1. High Quality Code

Code must be of high quality. In particular:

1. Code should be neat and readable, with consistent indentation and proper use of whitespace.
2. Comments in code must be correct.
3. Files must be organized in accordance with standard conventions.
   • In C++, split code appropriately among header and source files, and use #include in the proper places, and #ifndef to avoid multiple inclusion.
4. Code should not perform any actions visible to the client code or the user, other than those in its specification.
   • In particular, avoid debugging printout in the turned-in version of your code.
5. Unnecessary or duplicate code should be avoided.
   • In C++, silently written member functions should be used whenever possible. When they are used, the fact must be noted in a comment.
   • In C++, constructors should use initializers appropriately.
6. All functions should pass their parameters and return values in appropriate ways, and be defined in the appropriate place (e.g., inside a class? outside?).
   • In C++, overloaded operators need to be member or global, as appropriate.
7. Appropriate use should be made of language constructs that deny privileges.
   • In C++: const, private, etc.

2. Specific Standards

1. All source code must be in C++, as close as possible to the 1998 ANSI standard.
2. At the beginning of every file should be a comment indicating the file’s name, author, date, and purpose.
   • Note: The purpose comment does not have to be very long. Something like “Header for class Foo” is generally fine.
3. Before every function definition, except possibly main, there should be comments indicating preconditions and postconditions. For a member function, you do not need to include class invariants in these lists. If a function has no preconditions (or postconditions) then write “None”.
4. Before every class definition there must be comments indicating class invariants.
5. Only required headers should be included, and namespace pollution should be avoided.
   • In particular, do not write “using namespace std;”.
   • Also, where possible, avoid the “.h” system headers. For example, prefer <cstdlib> to <stdlib.h>.

3. Additional Standards

In addition, some assignments later in the class will need to meet the following standards. Students will be notified when these standards must be met.

1. Requirements on template parameter types must be documented.
2. If a function is not a template and not a member of a class template, then the exceptions it throws must be documented. (Often, this will be simply “Does not throw”.)
3. If a function is a template or a member of a class template, then indicate whether it is exception neutral, and whether it throws any additional exceptions.
4. If a function is a member or friend of a class, then its exception safety guarantee must be documented.

CS 311 Fall 2009: Coding Standards / Updated: 11 Sep 2009 / Glenn G. Chappell / ffggc@uaf.edu