JavaScript:SpiderMonkey:C Coding Style: Difference between revisions

Jump to navigation Jump to search
m
add whitespace
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.
Confirmed users
446

edits

Navigation menu