JavaScript:SpiderMonkey:C Coding Style

Function Names

• Public function names begin with JS_ followed by capitalized "intercaps", e.g. JS_NewObject.
• Extern but library-private function names use a js_ prefix and mixed case, e.g. js_SearchScope.
• Most static function names have unprefixed, mixed-case names: GetChar.
• But static native methods of JS objects have lowercase, underscore-separated or intercaps names, e.g., str_indexOf.

Other Symbols

• Library-private and static data use underscores, not intercaps (but library-private data do use a js_ prefix).
• Scalar type names are lowercase and js-prefixed: jsdouble.
• Aggregate type names are JS-prefixed and mixed-case: JSObject.
• Macros are generally ALL_CAPS and underscored, to call out potential side effects, multiple uses of a formal argument, etc.

Tabs and Spaces

• Four spaces of indentation per statement nesting level.
• Tabs are taken to be eight spaces, and an Emacs magic comment at the top of each file tries to help. If you're using MSVC or similar, you'll want to set tab width to 8, and help convert these files to be space-filled. Do not add hard tabs to source files; do remove them whenever possible.
• Observe the 80-column limit per line, and break down lines that are too long.
• Do not use spaces between a function name and its arguments list, or between an array name and the square bracket. Also, do no use spaces after a bracket. Use a space after a comma to separate arguments.

JS_SetContext ( rt, cx ); // bad
JS_SetContext(rt, cx);    // OK

• Use a space between a C keyword and parentheses.

if(condition)             // bad
if (condition)            // OK

Indentation and Bracketing

• Function arguments should be lined up aligned with the opening parenthesis.

JS_SetContext(rt,         // bad
             cx);
JS_SetContext(rt,         // OK
              cx);

• An opening bracket is placed on the same line as the preceding statement.

if(condition)             // bad
{
}
if(condition) {           // OK
}

• Do not use multiple statements in one line. Indent a follow-up statement in the next line.

if(condition) break;      // bad
if(condition)             // OK
    break;

• If a statement covers multiple lines, use brackets.

if(condition)             // bad
    CallThisMethod(argument1,
                   argument2);
if(condition) {           // OK
    CallThisMethod(argument1,
                   argument2);
}

Program Flow

• Keep indentation at a minimum.
  • Prefer return statements over brackets or "else" statements.

void MyFunction(int n) {
    if(n) {               // bad
        ...
    }
}
void MyFunction(int n) {
    if(!n)
        return;           // OK
    ...
}

• • If an "if" statement contains a return statement, do not use "else".

if (condition) {          // bad
    DoThis();
    return;
}
else
    DoThat();
if (condition) {          // OK
    DoThis();
    return;
}
DoThat();

Comments

• Always use C style comments. Never use C++ style comments.
• Terminate a comment with a period.

/* This is a good comment. */

• Align multiline comments with any indentation, and start every line with an asterisk. Start a multiline comment with an empty line. Leave the first line of the comment blank. Multiline comments should also be bracketed.

if(condition) {
 
    /*
     * This is a lengthy
     * multiline comment.
     */
    DoYourStuff();
}

Entry Points and Callbacks

• DLL entry points have their return type expanded within a JS_PUBLIC_API() macro call, to get the right Windows secret type qualifiers in the right places for all build variants.
• Callback functions that might be called from a DLL are similarly macroized with JS_STATIC_DLL_CALLBACK (if the function otherwise would be static to hide its name) or JS_DLL_CALLBACK (this macro takes no type argument; it should be used after the return type and before the function name).