SpiderMonkey coding conventions

  • Revision slug: SpiderMonkey_coding_conventions
  • Revision title: SpiderMonkey coding conventions
  • Revision id: 66482
  • Created:
  • Creator: Jorend
  • Is current revision? No
  • Comment move from js/src/README.html

Revision Content

Naming conventions

  • 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.
  • And 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.

Linkage

  • 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).

Style

  • 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.

Revision Source

<h3 name="Naming_conventions"> Naming conventions </h3>
<ul><li> Public function names begin with <code>JS_</code> followed by capitalized "intercaps", e.g. <code>JS_NewObject</code>.
</li></ul>
<ul><li> Extern but library-private function names use a <code>js_</code> prefix and mixed case, e.g. <code>js_SearchScope</code>.
</li></ul>
<ul><li> Most static function names have unprefixed, mixed-case names: <code>GetChar</code>.
</li></ul>
<ul><li> But static native methods of JS objects have lowercase, underscore-separated or intercaps names, e.g., <code>str_indexOf</code>.
</li></ul>
<ul><li> And library-private and static data use underscores, not intercaps (but library-private data do use a <code>js_</code> prefix).
</li></ul>
<ul><li> Scalar type names are lowercase and <code>js</code>-prefixed: <code>jsdouble</code>.
</li></ul>
<ul><li> Aggregate type names are <code>JS</code>-prefixed and mixed-case: <code>JSObject</code>.
</li></ul>
<ul><li> Macros are generally <code>ALL_CAPS</code> and underscored, to call out potential side effects, multiple uses of a formal argument, etc.
</li></ul>
<h3 name="Linkage"> Linkage </h3>
<ul><li> DLL entry points have their return type expanded within a <code>JS_PUBLIC_API()</code> macro call, to get the right Windows secret type qualifiers in the right places for all build variants.
</li></ul>
<ul><li> Callback functions that might be called from a DLL are similarly macroized with <code>JS_STATIC_DLL_CALLBACK</code> (if the function otherwise would be static to hide its name) or <code>JS_DLL_CALLBACK</code> (this macro takes no type argument; it should be used after the return type and before the function name).
</li></ul>
<h3 name="Style"> Style </h3>
<ul><li> Four spaces of indentation per statement nesting level.
</li></ul>
<ul><li> 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. <b>Do not add hard tabs to source files; do remove them whenever possible.</b>
</li></ul>
Revert to this revision