JavaScript:SpiderMonkey:C++ Coding Style

Basis

The JavaScript:SpiderMonkey:Coding_Style C guidelines apply unless overridden here. If this becomes awkward we should fork and diverge instead of referencing.

The rest of this page is a strawman proposal. Feel free to add, amend, or even correct if something is obviously wrong. Raise issues in the newsgroup.

Namespaces

• Instead of JS/js and JS_ prefixing for public function and type names, respectively, use

namespace JS { ... }

• Instead of js_ prefixing for library-private and "friend" functions,

namespace js { ... }

• Other namespaces? Are these names too short and likely to collide?

Classical OOP

• Most structs can become classes, with associated functions becoming methods. This already started for the upvar2 bug.
  • Style detailing: mrbkap suggests left brace before class body on its own line in column 1 to match function style and facilitate vim navigation. People do this already when inheriting, since the left brace can get lost in the superclass(es).

class JSObject
{
     ...
}

• Most macros become inline helpers. With LiveConnect gone on mozilla-central, we can make the helpers methods of relevant structs or classes finally, instead of static inline functions.
• Based on 20+ years of bad experiences, we are going to go slow and resist virtual methods and bases, MI, and the like. Function pointer tables for now, as before -- see JSObjectOps needs a make-over.
• Templates are good, Mozilla has positive experience and the portability is there for the kind of RAII helpers we need.
• No exceptions, so std is hard to use. Sayrer suggests using v8's vector type to get started.
• We would benefit from better hashtable API. Implementation, in targeted ways (delegate free and removed sentinel representation so that the double hashtable entry can be a word; improve bit-mixing into multiplicative hash if the cycle costs can be supported), but measurement is required and we should understand down to the bits what is going on.