Confirmed users
446
edits
m (→Control Flow: Fix inconsistency with previous style guideline.) |
m (add whitespace) |
||
Line 1: | Line 1: | ||
== Functions == | == Functions == | ||
* Public function names begin with JS_ followed by capitalized "intercaps", e.g. JS_NewObject. | * 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. | * Extern but library-private function names use a js_ prefix and mixed case, e.g. js_SearchScope. | ||
Line 17: | Line 18: | ||
== Other Symbols == | == Other Symbols == | ||
* Library-private and static data use underscores, not intercaps (but library-private data do use a js_ prefix). | * 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. | * Scalar type names are lowercase and js-prefixed: jsdouble. | ||
Line 23: | Line 25: | ||
== Indentation == | == Indentation == | ||
* Use spaces, not tabs. There should be no tabs in source files. | * Use spaces, not tabs. There should be no tabs in source files. | ||
* Four spaces of indentation per statement nesting level. | * Four spaces of indentation per statement nesting level. | ||
Line 38: | Line 41: | ||
= Whitespace in declarations = | = Whitespace in declarations = | ||
These rules are inconsistently applied. Be consistent with the code you're editing rather than adhere too closely to these guidelines! | These rules are inconsistently applied. Be consistent with the code you're editing rather than adhere too closely to these guidelines! | ||
Line 69: | Line 73: | ||
= Other whitespace = | = Other whitespace = | ||
* There used to be a strict 80-column limit per line. The hard limit is now 100 columns, a change that dates to 2008. Break down lines that are too long. | * There used to be a strict 80-column limit per line. The hard limit is now 100 columns, a change that dates to 2008. Break down lines that are too long. | ||
** Overlong conditions break after each && or || operator. | ** Overlong conditions break after each && or || operator. | ||
Line 100: | Line 105: | ||
== Control Flow == | == Control Flow == | ||
* Minimize indentation using return, break, and continue where appropriate. Prefer return (break, continue) statements to cast out abnormal cases, instead of nesting "if/else" statements and indenting the common cases. | * Minimize indentation using return, break, and continue where appropriate. Prefer return (break, continue) statements to cast out abnormal cases, instead of nesting "if/else" statements and indenting the common cases. | ||
void | void | ||
Line 147: | Line 153: | ||
== Comments == | == Comments == | ||
* Always use C style comments. Never use C++ style comments. | * Always use C style comments. Never use C++ style comments. | ||
* Terminate a comment with a period (so try to make comments be complete sentences). | * Terminate a comment with a period (so try to make comments be complete sentences). | ||
Line 162: | Line 169: | ||
== Entry Points and Callbacks == | == 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. | * 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). | * 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). | ||
== Data Types and Alignments == | == Data Types and Alignments == | ||
* As with all Mozilla code, SpiderMonkey needs to compile and execute correctly on many platforms, including 64-bits systems. | * As with all Mozilla code, SpiderMonkey needs to compile and execute correctly on many platforms, including 64-bits systems. | ||
* JS and NSPR have common roots in the dawn of time (Netscape 2), and the <code>JS_THREADSAFE</code> mode of building SpiderMonkey depends on NSPR, so reading the [http://www.mozilla.org/projects/nspr/reference/html/ NSPR documentation] is well worth your while. | * JS and NSPR have common roots in the dawn of time (Netscape 2), and the <code>JS_THREADSAFE</code> mode of building SpiderMonkey depends on NSPR, so reading the [http://www.mozilla.org/projects/nspr/reference/html/ NSPR documentation] is well worth your while. | ||
* Not all 64-bit systems use the same integer type model: some are "LP64" (long and pointer are 64 bits, int is 32 bits), while others are "LLP64" (only long long and pointer are 64 bits; long and int are 32 bits). | * Not all 64-bit systems use the same integer type model: some are "LP64" (long and pointer are 64 bits, int is 32 bits), while others are "LLP64" (only long long and pointer are 64 bits; long and int are 32 bits). | ||
* Use size_t for unsigned number of bytes variables, ptrdiff_t for signed pointer subtraction results. In particular, do not use uintN, which is just shorthand for unsigned int, and so may not be big enough. | * Use size_t for unsigned number of bytes variables, ptrdiff_t for signed pointer subtraction results. In particular, do not use uintN, which is just shorthand for unsigned int, and so may not be big enough. |