All work must be written according to this coding standard, which covers
naming conventions, spacing, code layout, and probably generally things
that you should or should not do. Ultimately these are guidelines to which
your code should conform.
Note that rules may be added or modified over the course of the semester. If
you have a question about how things should look or be done, ask.
Spacing
Tabstops must be set at 4 spaces, do not use tab characters.
A line of code should not exceed 80 characters and must not exceed 100
characters. Code must never be dynamically word-wrapped. Long lines
can be broken and indented (as is frequent with cout statements).
Generally, separate blockprocessor code from C++ with a blank line. For example:
#include <iostream>
#include <fstream>
// Code starts here.
Separate all function and class definitions by at least one blank line. For example:
void hello()
{ cout << "hello "; }
void world()
{ cout << "world" << endl; }
Layout
Layout can refer to the organization of code within a file or the members of a
class.
Source files should have the following organization:
// Include statements#include <cmath>
// Forward declarationsstruct point;
// Function declarationsdouble distance(point const& a, point const& b);
// Type definitionsstruct point
{
int x;
int y;
};
// Function declarationsdouble distance(point const& a, point const& b)
{ return std::sqrt(...); }
Forward declarations should only be used as needed. They are included here as part
of the example, but can easily be left out.
Classes should have the following layout:
class point
{
// Local associated typestypedefint coordinate;
// Constructors
point();
// Operators
point& operator=(point const&);
// Member Functionsbool is_origin() const;
// Member Variables
coordinate x;
coordinate y;
};
Do not use multiple declarator syntax for member variables. One line, one
variable.
Naming Convention
Your source (implementation) files must end in the extesion .cpp, and
your header files must end in .hpp. If you choose to create implementation
files (headers with function definitions), they must end in .ipp.
You must follow the C/C++ (and Boost) standards naming conventions. In general
C and C++ use all lowercase, separating words with underscores. For example:
class ostream_iterator { };
double euclidean_distance(double, double);
One exception is concept names, which use mixed cases such as LessThanComparable
and ForwardIterator.
Identifer (variable) names should be sufficiently descriptive, either by being
explicit (e.g., sum) or by convention (e.g., i).
Member variables may be written as m_ or with a single leading or trailing
underscore, or as typical variables.
Do not use Hungarian notation.
Type Expressions
A type expression is a sequence of identifiers and qualifiers that denotes a type.
Do not use abbreviations for primitive types. Write unsigned int instead
of unsigned.
When using const, put it after the type name. For example:
int const x = 10;
string const& s = t;
char const* p = argv[0];
Attach reference and pointer qualifiers to their left-most type name or
const-volatile qualifier. For example:
int* p = &x;
int& r = x;
See the previous block for more examples.
Braces
Should you put the brace on the same line or the next line? If the brace opens a
namespace, you should put it on the next line. This applies to classes, functions,
namespaces, and sometimes enumerations. If the brace is part of a control statement,
you should put it on the same line. For example:
void is_prime(int n)
{ // new namespace, brace starts on next linefor(int i = 0; i <= sqrt(n); ++i) { // control staement, brace on same lineif(n % i == 0) { // control statement, brace on same linereturn false;
}
}
return true;
}
If the block is trivial or empty, both braces can be collapsed to the same line.
void fail()
{ return false; }
Using Namespaces
Never write using namespace in a namespace scope
(i.e., global or otherwise) in a header file. It is acceptable to write it in
a source file.
You may choose to write using in a function
definition.
double distance(point const& a, point const& b)
{
// Use one (not both) of the following forms
using namespace std; // Option 1
using std::sqrt; // Option 2 (preferred)return sqrt(...);
}
Commenting
You must comment your code. What makes a good comment is always debatble.
In general, try to make your comments both precise and consise. Proper grammar
and spelling is a must.
There are essentially two types of comments: documentation and implementation.
Documentation comments describe types and interfaces and should be commented using
Doxygen style. Interface
documentation must describe the element completely (responsibilities, return values,
parameters, exceptions, etc.). Doxygen documentation can be extracted and built
into a web page.
/**
* Returns the distance between the points a and b.
*/double distance(point const& a, point const& b);
Implementation comments describes what code does and, most importantly, why.
These comments are essentially notes to yourself and other people reading the code
to help describe the rationale behind the code's behavior.
void is_prime(int n)
{
// Search for factors.for(int i = 0; i <= sqrt(n); ++i) {
// The remainder is 0 if it's a factor.if(n % i == 0) {
return false;
}
}
return true;
}
i