Labs/Jetpack/Reboot/Best Practices: Difference between revisions
Jump to navigation
Jump to search
(Added question about how Cuddlefish modules are used) |
(added another bullet point) |
||
| Line 14: | Line 14: | ||
* API design | * 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? | * 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. | |||
Revision as of 19:02, 1 February 2010
The following are best practices for reboot development. Nothing is (yet) set in stone, so propose and debate and stuff.
- See Labs/Jetpack/Reboot/Style_Guide for coding style guidelines/discussion.
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.