Skip to content
Dmitry Panin edited this page Nov 17, 2013 · 1 revision

These rules are not "must" but "nice to have". People who don't respect them won't be shot in the head, people who respect them are cool guys.

We use the Unix encoding for carriage returns. If you use windows, there's probably an option for that in your editor. Visual Studio will usually ask you when there's a strange file. Always reply "Unix" 4 space indentation. Don't use tabs for indentation, use spaces. One tab = 4 spaces. There is a setting for this in Visual Studio. the = sign should be separated by spaces. a = 1; is good. a=1; is not. a= 1; and a =1; are even worse. curly braces go on a new line

if (foo)
{
    bar();
    stuff();
}

If a scope contains only one line, it is ok to omit the curly braces. It is fine to have them too. The following are all ok, use your judgment here:

if (foo)
{
    bar();
}
if (foo)
    bar();
if (foo) bar();

parameters spacing: no space between function name and parenthesis, space after a comma separating parameters:

int foo(int a, int b)
this.foo(a, b);

Avoid to nest if/while/for too much. As a rule of thumb, If you have more than 3 "nested loops" levels, there is probably a better way As a consequence of the rule above, we suggest to return early:

if (not_applicable) return; // And don't care any more

in header (.h) files, use the following order: private, protected, public > Attributes then methods, group them by "goal/semantics" rather than alphabetically. No specific rule for .cpp files

MyClass
{
    protected:
        int mHeight;
        int mWidth;

        float stuff;

        int foo();

    public:
        int mPublicVar;

        MyClass(int stuff);
};

Variable naming: we use camelCase and a simple prefix for global variables and attributes: gGlobal, mAttribute, noSpecificRuleForLocalVars. If possible we want to avoid global variables. First letter is lowercase. Variable Naming: Function names and class declarations should be capitalized, whereas objects/variables shouldn't. Variable naming: on top of the above rules, For globals, constants, and class attributes, use full words, except in the rare case where an abbreviation would be more canonical and easier to understand. For local variables, use your best judgment and a balance between readability and efficiency. Constants: We are still debating between UPPERCASE_CONSTANT and kConstant no magic numbers, use enum or define instead:

if (Constants::MAGIC_NUMBER == myVariable)

is good,

if (55 == myVariable)

is not. We love comments in the code, as long as they don't state the obvious we don't need

int getHeight(); //gets the Height

we love

superHack(); // There's a bug with some cards that require to call this hack, see http://code.google.com/p/wagic/issues/detail?id=123
Clone this wiki locally