Javascript and other coding standards

Addy Osami article link to a number of guides

D. Crockford
http://javascript.crockford.com/style1.html
http://javascript.crockford.com/style2.html
http://javascript.crockford.com/code.html
 But we use a++ and may differ some re whitespaces.

Googles js style guide

Love this guy

We've followed yuis code comments guide

Some useful info here in these isobar standards but more concise would be better imo.

We use jshint and confugure it for our rules for building. USing automated tools as much as possible is critical. Then code walkthroughs can concentrate on higher order questions such as proper use of design patterns, right architecture etc.

I think it better to agree on reference standards to follow and then only call out anything extra or different from those. There's lots of good references and it fails to be maintained over time otherwise.


Below is an example of rules on a previous project.

Coding standards

• your code must lint and you must run the grunt task to lint your code before commit to git
• follow these Coding Standard by Crockford and also Googles
• functions should be short (approx. 30 lines or less typically) and typically do 1 thing well. Above 30 lines and you should really consider re-factor. Above 50 and you must re-factor.
• stay DRY i.e. do not repeat yourself. If you have code thats repeated/copied it needs to be re-factored to not repeat
• it is expected developers know, can and do apply standard software patterns such as Factory, Facade, Composite, State, Mediator, Singleton etc. and of course MVC.
• you cannot violate the principals of mvc e.g. should never refer to views from models instead controllers listen to model events and update the view accordingly.
• know and avoid the bad parts and the awful parts of the language
• code unobtrusive javascript
• goal: every dev should present a code walkthrough once a week [2 weeks max] (as well as attending other devs walkthroughs)
• cross browser test your code including IE7, check the console for any error messages
• use spaces not tabs, set tab to 4 spaces (sorry tabs fans..one reason is our jslinter errors mixing of tabs and spaces)
• Comment each class and method. Adopt YUIDoc javascript block commenting guidelines (YUIDoc and YUIDoc Syntax Ref). The only suggestion I would make regarding their examples is to add a single space after the first /** line so all the *’s line up in a nice column.

Naming

See coding standards above to start
Classes start with Upper case letter e.g. ResultsModel
Models end in Model, Views end in View, Router ends in Router e.g. ResultsModel, ResultsView, AppRouter etc.

View handlers start with the word ‘handle’ e.g. ‘click .addRow’: ‘handleAddNewRow’

Events triggered are defined as class constant variables 
e.g. EVENT_OPTION_MOUSEOVER: ‘optionMouseover’,
…they can then be referenced like: this.trigger(v.StepOptionView.EVENT_OPTION_MOUSEOUT, this, this.model);

private methods to be prefixed with underscore

Backbone guidelines

Prefer to inject references at creation time than to have an object hardcode references inside it e.g.
models.resultsModel = new models.ResultsModel({reference1: models.objA, reference2: models.objB});
…is better than having code in ResultsModel which directly refers to models.objA.
See more here for Dependency Injection

When to create a view?

• ask yourself is this able to change independently
  Also generally 1 view 1 template

Models and views?

• Generally you will have 1 model to 1 view. Don’t be concerned about creating too many models or views. These classes are lighweight and often having less objects ends up with classes trying to do too much.

Use the backbone el as much as possible, helps set event scoping scoped to your view.

Dust guidelines

Please see the github repo landing page for template conventions you must follow.

Where to include dust partials, in the template or from backbone view render()

• prefer to include partials from within other templates, render calls include overhead

You can call functions from a dust template, there’s an example in SelectSizeRowView e.g. quantityMatch

There are a number of custom helpers we added including: dustIdxPlusOne, formatMoney, formatMoneyWithSymbol, formatDateMonthDayYear etc. Please learn and use them e.g. 
{totalPrice|formatMoneyWithSymbol}

Unit Testing with Jasmine

We want developers to write unit test. We’re using Jasmine. There are instructions on the GitHub repo for how to write Jasmine tests within out app. See section “Writing specs for unit testing”
Here’s a good article to start learning