Confirmed users
1,345
edits
JavaScript:SpiderMonkey:Coding Style: Difference between revisions
Jump to navigation
Jump to search
JavaScript:SpiderMonkey:Coding Style (view source)
Revision as of 01:16, 26 April 2013
, 26 April 2013no edit summary
Nnethercote (talk | contribs) No edit summary |
Nnethercote (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
= 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. | ||
| Line 17: | Line 17: | ||
} | } | ||
= 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). | ||
| Line 24: | Line 24: | ||
* Macros are generally ALL_CAPS and underscored, to call out potential side effects, multiple uses of a formal argument, etc. | * Macros are generally ALL_CAPS and underscored, to call out potential side effects, multiple uses of a formal argument, etc. | ||
= 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. | ||
| Line 121: | Line 121: | ||
} | } | ||
= 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. | ||
| Line 170: | Line 170: | ||
DoTheOther(); | DoTheOther(); | ||
= Comments = | |||
* | * In C files, always use C style comments. C++ comments are ok otherwise. | ||
* 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). | ||
/* This is a good comment. */ | /* This is a good comment. */ | ||
* | // This is also a good comment. | ||
* For C-style multiline comments, align with any indentation, and start every line with an asterisk. Asterisks stack in the same column. Precede the multiline comment with one empty line unless the prior line ends in a left brace. The first line of the comment contains only leading space followed by <code>/*</code>. Multiline comments should also be bracketed. | |||
<pre> | <pre> | ||
if (condition) { | if (condition) { | ||
/* | /* | ||
* This is a lengthy | * This is a lengthy C-style | ||
* multiline comment. | * multiline comment. | ||
*/ | */ | ||
// This is a length | |||
// C++-style comment | |||
DoYourStuff(); | DoYourStuff(); | ||
} | } | ||
</pre> | </pre> | ||
= 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 = | |||
* 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. | ||
| Line 197: | Line 200: | ||
* 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. | ||
= C++ = | = C++ = | ||