Labs/Jetpack/Reboot/Best Practices: Difference between revisions

Latest revision as of 23:57, 4 March 2010

HEY
This page has been superseded by documentation contained in the Jetpack SDK.

@@ Line 1: / Line 1: @@
-The following are best practices for reboot development.  Nothing is (yet) set in stone, so propose and debate and stuff.
+{{Jetpack/Moved to SDK}}
-* [[Labs/Jetpack/Reboot/Style_Guide|General Coding Style Guide]] for coding style guidelines/discussion.
-We also need to cover:
-* how to namespace packages (e.g., <tt>require("foo/bar/baz")</tt>)
-* out-of-code documentation (e.g., tutorials and guides)
-* unit testing
-* memory leak detection
-* module unloading
-* security
-* localization
-* API design
-* Some Cuddlefish modules, like file.js, take pains to be broadly compatible as JS modules and loadable as-is in Web pages, in addition to being SecurableModules used in Jetpack.  Do we really want to go that route for all modules?
-* Creating code that can exist side-by-side with different versions of itself; implies not mutating the outside environment in certain ways.
-* When creating objects, do we want <tt>jetpack.thing()</tt> or <tt>new jetpack.Thing()</tt>?
-** Atul has found the case of forgetting the "new" operator to be unforgivingly difficult to debug.
-** Atul has also found that "new" operator problems are hard to debug when the operator associates w/ a different operand than one intends, e.g. <tt>new require("foo").Bar()</tt>.