-
Notifications
You must be signed in to change notification settings - Fork 0
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.
Tab for indentation, spaces to align variable name.
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:
}
Same line please!
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.
*/
/**
* 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) {
...
}
Prefer alphabetical order when possible (for example, imports, functions, member variables).
Camelcase for everything:
int someVariableName;
Highly prefer fully written variables:
int critical;
int getCritical() { return critical; }
Avoid single letter arguments:
void useCritical(int critical) {
...
}
No space between keyword / function and parentheses, but a space to separate the bracket:
void function(args) {
...
}
& 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) { ... }
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).