If you embark on an involved open source or private project, you’re likely to work with other people. It’s important to be upfront about the goals of the project and the style of development.
These are the practices we recommend to use to develop this framework:

  • Verbose: Variable and method names should be verbose so things are easy to find and understand
  • Portable: Browsers and console should be catered for
  • Explicit: Code should be quick to understand
  • Comments: Let’s keep comment noise down. Comments should be succinct. TODO and FIXME are acceptable.
  • Simple: Keep code simple. Let’s not bore readers!
  • Indentation: Two spaces
  • Semicolons: People might want to minify this library — let’s keep simicolons!
  • Quality: JsLint and reader comments!
  • Testing: Test first development for both browsers and console
  • Versioning: GitHub to the rescue

In detail:

DRY. Do not repeat yourself. Code duplication is evil.

KISS. Keep it simple stupid. If its more complicated then needs be you’re doing it wrong.

SOLID. SOLID (object-oriented design) – Wikipedia. Read it. Memorize it.

In object-oriented computer programming, the term SOLID is a mnemonic acronym for five design principles intended to make software designs more understandable, flexible and maintainable. The principles are a subset of many principles promoted by Robert C. Martin. T

hough they apply to any object-oriented design, the SOLID principles can also form a core philosophy for methodologies such as agile development or adaptive software development.[3]

The SOLID acronym was introduced by Michael Feathers.

Single responsibility principle[4]
class should have only a single responsibility (i.e. changes to only one part of the software’s specification should be able to affect the specification of the class).
Open/closed principle[5]
“software entities … should be open for extension, but closed for modification.”
Liskov substitution principle[6]
“objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract.
Interface segregation principle[7]
“many client-specific interfaces are better than one general-purpose interface.”[8]
Dependency inversion principle[9]
one should “depend upon abstractions, [not] concretions.”[8]

Write unit tests. Aim for high coverage.

Always be refactoring. If you edit a file, do something small to clean up the code.