CS 106B/X Style Guide

These are some of the general style qualities that we expect your programs to have in order to receive full credit. This is not an exhaustive list; please also refer to each assignment spec for other style practices to follow. Certainly it is possible to write good code that violates these guidelines, and you may feel free to contact us if you are unclear about or disagree with some of them. But we do expect you to follow these rules (unless there is an error in this document). In most professional work environments you are expected to follow that company's style standards. Learning to carefully obey a style guide, and writing code with a group of other developers where the style is consistent among them, are valuable job skills.

This document is a work in progress.
Any guidelines written here are in addition to what is mentioned in the given assignment's spec, so you are responsible for reading that spec and following its instructions. If there is ever a conflict between this style guide and an assignment spec, follow the assignment spec.

Last updated Mon 2016/10/03


Whitespace and Indentation
Naming and Variables
Basic C++ Statements
Redundancy
Efficiency
Comments

Here is a decent overall example of a good comment header on a function. Not every comment header needs to be this long, but since this function takes a parameter and returns something, it needs to mention several things.

class Person {
    public:
        bool engageTo(Person& other);
    ...
}

/*
 * Sets this person to be engaged to the given other person.
 * If either this person or other were previously engaged, their previous
 * engagement is called off and the previous partner is set to be single.
 * Returns true if this person was previously engaged before the call.
 */
bool Person::engageTo(Person& other) {
    ...
}
Functions and Procedural Design
Class Design