Current

This document is valid for the current version of Plone.

Coding Standards

by Plone Documentation Team last modified Feb 26, 2011 09:13 PM
Contributors: Mikko Ohtamma, Martin Aspeli, Kamon Ayeva, Israel Saeta Pérez

JSLint

All JavaScript components that are incorporated into the Plone core must pass JSLint code quality tests. At some point in the 4.x series, this will become part of Plone’s continuous integration testing.
JSLint has many options, and it is our goal that our code pass “The Good Parts” tests. A couple of acceptable deviations from the good parts settings are to:

  • Assume a browser /*jslint browser: true */;
  • Relax white-space requirements (removing “white: true”) to allow for idiomatic composition of jQuery cascades.
  • Assume availability of the globals jQuery, browser, window and location.

You may set these options by including at the top of your JavaScript file:

/*jslint white:false, onevar:true, undef:true, nomen:true, eqeqeq:true, plusplus:true, bitwise:true, regexp:true, newcap:true, immed:true, strict:false, browser:true */

/*global jQuery:false, document:false, window:false, location:false */

These settings are available as a file in Products/CMFPlone/skins/plone_ecmascript/js-standards.js. If you use those settings, you only need set the options for any deviations needed by the current file. Deviations like turning off the regular-expression "." prohibition, are perfectly reasonable when porting old code, but should be avoided in new code.

A common way to execute a command-line jslint test using these options would be to execute:

cat js-standards.js accessibility.js | jslint

if you were testing the “accessibility.js” file. JSLint is also available as a plugin for most popular web code editors and can be set to test on save. An example of setting up TextMate to run jslint on save:

JSLint on Save

Strict Mode

Do not include the “use strict” directive unless you are testing in an environment that will enforce the strict standard. Otherwise, your code may fail when execu

ted on future browsers.

Globals

JavaScript components should create as few as possible global variables. If a component must create globals, it should only create one: a namespace object with a very distinctive name. Please document your new global at the top of the component file.