Skip to content
Kevin Zhang edited this page Apr 28, 2017 · 7 revisions

Style Guide

This is just a super quick rundown of the current programming style I have been using. Generally, refer to Google's style guide.

Whitespace

Tab for indentation, spaces to align variable name.

Access modifiers

I think there's a nontrivial number of editors that bring these to the back, but I'd prefer them tabbed as well:

class Class {
	public:
	private:
}

Brackets

Same line please!

Class Documentation

Favor writing in header files when possible (unless there is none, like in many of the test sources). If you really want to, you can put original author as well - seeing as how people tend to contribute and modify these files anyway, I've always found it to be somewhat redundant / useless to include that.

/**
 * folder/filename
 * @author Kevin Zhang
 * Description of the class and any other interesting notes you may want to include.
 */

Function Documentation

/**
 * int function()
 * Some description of the function, if necessary.
 * @param
 *    variable: some description
 *
 * @modifies
 *    modifiedVariable: some explanation
 *
 * @return some variable or other return value, if necessary
 */
int feClass:function(const int variable, int &modifiedVariable) {
...
}

Ordering

Prefer alphabetical order when possible (for example, imports, functions, member variables).

Naming

Camelcase for everything:

int someVariableName;

Highly prefer fully written variables:

int critical;
int getCritical() { return critical; }

Avoid single letter arguments:

void useCritical(int critical) {
...
}

Parentheses

No space between keyword / function and parentheses, but a space to separate the bracket:

void function(args) {
...
}

Pointer Tokens

& and * should always directly precede the variable or argument; I don't even understand why this isn't standard practice.

int a = 0;
int *b = &a;
void function(int &arg) { ... }

Test Cases

This project uses Catch, a single-header automated test framework for C++ that is extremely easy to use (at least, in my opinion). Test cases are pretty simple to write, and should either go in their own .cpp file or added to one of the existing ones, all of which must go under /tests.

Test sources should always contain the following generic header:

/**
 * tests/<source>.cpp
 * Generic description of what tests are contained.
 */

Test cases should generally have a descriptive, concise name with proper capitalization. Test labels should be wrapped in brackets, and contain some sort of descriptive tag (if all else fails, just use the the object name):

TEST_CASE("Generic test name", "[combat]") {
...
}

Group similar test cases together under the same test case, using the SECTION macro to group them. SECTION labels should also be properly capitalized, and describe the following tests:

SECTION("Generic operations") {
...
}

Test cases should be thorough and, at a bare minimum, test each function (even trivial ones).

Clone this wiki locally