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

From MozillaWiki
< Labs‎ | Jetpack‎ | Reboot
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
The following are best practices for reboot development.  Nothing is (yet) set in stone, so propose and debate and stuff.
The following are best practices for reboot development.  Nothing is (yet) set in stone, so propose and debate and stuff.


* [[Labs/Jetpack/Reboot/Style_Guide General Coding Style Guide]] for coding style guidelines/discussion.
* [[Labs/Jetpack/Reboot/Style_Guide|General Coding Style Guide]] for coding style guidelines/discussion.


We also need to cover:
We also need to cover:

Revision as of 18:22, 5 February 2010

The following are best practices for reboot development. Nothing is (yet) set in stone, so propose and debate and stuff.

We also need to cover:

  • how to namespace packages (e.g., require("foo/bar/baz"))
  • 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 jetpack.thing() or new jetpack.Thing()?
    • 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. new require("foo").Bar().