JavaScript:SpiderMonkey:C++ Coding Style: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
 
(31 intermediate revisions by 7 users not shown)
Line 1: Line 1:
== Basics ==
#REDIRECT [[JavaScript:SpiderMonkey:Coding_Style]]
 
The [[JavaScript:SpiderMonkey:C_Coding_Style|C Coding Style 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 [http://groups.google.com/group/mozilla.dev.tech.js-engine/ newsgroup].
 
C++ is powerful, with many degrees of freedom and some attractive nuisances. We should aspire to use it in a lean, close-to-the-metal fashion, and avoid style over substance [http://www.bikeshed.com/ bikeshedding].
 
== 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=upvar2 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
{
      ...
}
** An easy [https://bugzilla.mozilla.org/show_bug.cgi?id=489419 starter bug] to steal and patch.
* 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=408416 JSObjectOps needs a make-over].
* Templates are good, Mozilla has positive experience and the portability is there for the kind of [http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization 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.
 
== References ==
 
* [https://developer.mozilla.org/en/Mozilla_Coding_Style_Guide Mozilla's coding style guide].
* [http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml Google's C++ coding style guide].

Latest revision as of 00:49, 26 April 2013

Redirect to:

Retrieved from "https://wiki.allizom.org/index.php?title=JavaScript:SpiderMonkey:C%2B%2B_Coding_Style&oldid=649673"