SproutCore

SproutCore Guides

These guides are designed to help you write and perfect your code.

Committing Code

So, you’re ready to push some code into the public repo? Here’s a list of things you can do to make sure your code gets past the review process.

1 Conform to SC Style Guides

Yeah, this is pretty obvious. If you haven’t already go read them.

2 Must Pass JS lint

Javascript can be beautiful and annoying all at the same time. Crockford’s JSLint is a god send and helps check for common mistakes like:

  • Undefined global vars
  • use of == and != instead of === and !==
  • Extra or missing commas

The following JS lint config can be used in combination with the SproutCore Textmate bundle.

Install it at <path to your Textmate bundles>/SproutCore.tmbundle/Support/bin/prefs.js


var JSLINT_PREFS = {
    adsafe     : false, // if ADsafe should be enforced
    bitwise    : false, // if bitwise operators should not be allowed
    browser    : true,  // if the standard browser globals should be predefined
    cap        : false, // if upper case HTML should be allowed
    debug      : true,  // if debugger statements should be allowed
    eqeqeq     : true, // if === should be required
    evil       : false, // if eval should be allowed
    forin      : true,  // if for in statements must filter
    fragment   : false, // if HTML fragments should be allowed
    laxbreak   : true,  // if line breaks should not be checked
    nomen      : false, // if names should be checked
    on         : false, // if HTML event handlers should be allowed
    passfail   : false, // if the scan should stop on first error
    plusplus   : false, // if increment/decrement should not be allowed
    regexp     : true,  // if the . should not be allowed in regexp literals
    rhino      : false, // if the Rhino environment globals should be predefined
    undef      : true,  // if variables should be declared before used
    safe       : false, // if use of some browser features should be restricted
    sidebar    : false, // if the System object should be predefined
    sub        : true,  // if all forms of subscript notation are tolerated
    white      : false, // if strict whitespace rules apply
    widget     : false, // if the Yahoo Widgets globals should be predefined
    indent: 2,
    predef: ['SC', 'require', 'sc_super', 'YES', 'NO', 'static_url', 'sc_static', 'sc_resource', 'sc_require', 'module', 'test', 'equals', 'same', 'ok', 'CoreTest', 'SproutCore', '$', 'jQuery', 'start', 'stop', 'expect', 'htmlbody']
};

3 Unit Tests

3.1 Don’t break anyone else’s tests

On stable builds, all of the unit tests should pass. On development branches, if there are broken tests because of a major project that someone on the Core Team is doing, you can ignore those failures.

3.2 Write good tests

Writing good unit tests is something often pontificated on by seasoned developers, so rather than waste time with a long essay I’ll just show some examples of good and bad unit tests:

3.2.1 View Unit Tests

test("basic", function() {
  var view = pane.view('basic');
  ok(!view.$().hasClass('disabled'), 'should not have disabled class');
  ok(!view.$().hasClass('sel'), 'should not have sel class');

  var input = view.$();
  equals(input.attr('aria-checked'), 'false',  'input should not be checked');

  var label = view.$('span.label');
  equals(label.text(), 'Hello World', 'should have label');
});

The above test is great because it verifies that the rendered DOM is correct.


test("basic", function() {
  var view = pane.view('basic');
  equals(view.get('title'), 'Hello World', 'should have label');
});

This test sucks because it only verifies that you can set a property on an object.

For more information see Writing Unit Tests.

3.3 Running Unit Tests

You can run the unit tests by using the test runner app http://localhost:4020/sproutcore/tests or by calling them manually:

  • All Tests: http://localhost:4020/<framework_or_app_name>/en/current/tests.html
  • Specific Tests: http://localhost:4020/<framework_or_app_name>/en/current/tests/path/to/your/tests.html

For example:

  • All of SproutCore’s datastore tests (link): http://localhost:4020/sproutcore/datastore/en/current/tests.html
  • Just the tests in the store directory (link): http://localhost:4020/sproutcore/datastore/en/current/tests/system/store.html
  • Just the find tests (link): http://localhost:4020/sproutcore/datastore/en/current/tests/system/store/find.html

For more information see Running Unit Tests.

4 Consistency

All code must be consistent with patterns found in the Application and within the Frameworks. example: MVC, Visitor, Statecharts don’t add special functionality without good reason!

5 Performance

Avoid Known Slow stuff:

  • .observes
  • nested run loops
  • looping
  • missing .cacheable()
  • code must be prove-ably fast with SC.Benchmark
  • keep in mind code size in kb, number of statements(IE!), doing too much on init

6 Maintainability

  • Don’t override private APIs
  • Be consistent and predictable
  • Make your classes extensible for other devs! (comment and modularize)
  • Use good OO practices
  • Reduce coupling between layers (parent classes should not know about their children → looking at you SC.View)
  • Refactor, don’t hackmake code better not worse!

7 Changelog