Coding Convention

The following guidance was built by looking at http://www.c-xx.com/ccc/ccc.php and considering what exists today in the CharkaCore codebase. ChakraCore does not consistently follow these patterns, nor is the team interested in making the entire codebase conform to them.

Please,

• DO not send PRs for style changes.
• DO give priority to the current style of the project or file you're changing even if it diverges from the general guidelines.

And now, the ChakraCore coding guidelines:

• Class names - Pascal case. No "C" prefix or the like. We like: FileName
• Interfaces - prefix with "I" like IFoo as opposed to FooInterface
• Typedefs - apply class naming rules.
• Variable names - use Camel case. We like: fileName
• Use m_ to prefix member variables. We like: m_fileName
• Group class data members together, please.
• It's OK to use prefix pointers with "p" but not required. Example: void swap(int* pLeft, int* pRight)
• Constants - Pascal case.
• Enumerations - Pascal case.
• Enumerators (the values within enumerations) - Pascal case.
• Namespaces - Pascal case.
• Functions - Pascal case.
• Preprocessor elements - ALL_CAPS
• Replace tabs with spaces.
• Indentation is 4 spaces.
• Keep line length reasonable, but 80 character limit is not necessary.
• Braces - use style A.

    Foo()  
    {  
        statement1;  
        statement2;  
    }

• Braces - include braces for single-statement blocks.

    if (condition)
    {
        a.single.statement;
    }

• Parenthesis and functions - please don't separate the opening paren from the function name. We don't like this:

    FooBar
    (    x,
         y,
         z
    );

This is OK:

    FooBar(
        x,
        y,
        z
    ); 

• Do not put "else" or "catch" on the same line as a bracket. No: } else
• No space before ',' or ';' Do put a space after. Except for '.'
• No "table style" variable/member declarations. No:

    Int    x;
    Double y;

• No spaces around brackets or parenthesis. No: invocation( argument );
• Add a space after a control flow keyword like for (int i; i < 10; i++)
• Avoid using assignment as a vaule-producing operation. No: if ((x = a[i]) >= '0' && x <= '9')
• Chained assignment is OK. x = y = z = 0;
• Switch statement formatting like this:

    switch (x)
    {
        case foo:
        {
            statement1;
            statement2;
        }
    };

• When declaring variables of pointer type group the asterisk with the variable, not the type being pointed to. Example int *x;
• Declare multiple variables on separate lines.
• Use nullptr
• Avoid auto except for long template names.
• No const_cast<>()
• Avoid const objects, and declaration of const methods. We don't really like the viral nature of const.
• Avoid the use of reference types.
• Avoid .inl files. Put implementations in the .cpp files. On Windows, PGO can make excellent inlining decisions.
• Do not use force_inline unless there is a proven need. Even then think twice.
• For methods defined in headers, like accessors for example, you can implement them on the same line as the signature.