Why have coding standards?

Coding standards help avoid common coding errors, improve the readability of code, and simplify
modification. They ensure that files within the project appear as if they were created by a single
person.
Following the standards means anyone will be able to understand a section of code and modify it, if
needed, without regard to when it was written or by whom.

HTML
Validation
All HTML pages should be verified against the W3C validator to ensure that the markup is well
formed. This in and of itself is not directly indicative of good code, but it helps to weed out problems
that are able to be tested via automation. It is no substitute for manual code review.
Self-closing Elements
All tags must be properly closed. For tags that can wrap nodes such as text or other elements,
termination is a trivial enough task. For tags that are self-closing, the forward slash should have
exactly one space preceding it:
1

<br />

Rather than the compact but incorrect:

1

<br/>

The W3C specifies that a single space should precede the self-closing slash (source).
Attributes and Tags
All tags and attributes must be written in lowercase. Additionally, attribute values should be
lowercase when the purpose of the text therein is only to be interpreted by machines. For instances
in which the data needs to be human readable, proper title capitalization should be followed.
For machines:
1

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

For humans:
1

<a href="http://example.com/" title="Description Here">Example.com</a>

Page 1 of 22

Quotes
According to the W3C specifications for XHTML, all attributes must have a value, and must use
double- or single-quotes (source). The following are examples of proper and improper usage of
quotes and attribute/value pairs.
Correct:
1
2

<input type="text" name="email" disabled="disabled" />

<input type='text' name='email' disabled='disabled' />

Incorrect:
1

<input type=text name=email disabled>

In HTML, attributes do not all have to have values, and attribute values do not always have to be
quoted. While all of the examples above are valid HTML, failing to quote attributes can lead to
security vulnerabilities. Always quote attributes.

Indentation
As with PHP, HTML indentation should always reflect logical structure. Use tabs and not spaces.
When mixing PHP and HTML together, indent PHP blocks to match the surrounding HTML code.
Closing PHP blocks should match the same indentation level as the opening block.
Correct:
1
2
3
4
5
6
7
8
9

<?php if ( ! have_posts() ) : ?>

<div id="post-1" class="post">
<h1 class="entry-title">Not Found</h1>
<div class="entry-content">
<p>Apologies, but no results were found.</p>
<?php get_search_form(); ?>
</div>
</div>
<?php endif; ?>

Incorrect:
1
2
3

<?php if ( ! have_posts() ) : ?>

<div id="post-0" class="post error404 not-found">
<h1 class="entry-title">Not Found</h1>

Page 2 of 22

4
5
6
7
8
9

<div class="entry-content">
<p>Apologies, but no results were found.</p>
<?php get_search_form(); ?>
</div>
</div>
<?php endif; ?>

CSS
Like any coding standard, the purpose of the CSS Coding Standards is to create a baseline for
collaboration and review within various aspects of the project, from core code to themes to plugins.
Files within a project should appear as though created by a single entity. Above all else, create code
that is readable, meaningful, consistent, and beautiful.
Within core stylesheets, inconsistencies will often be found. We are working on addressing these and
make every effort to have patches and commits from this point forward follow the CSS coding
standards. More information on the above and contributing to UI/front-end development will be
forthcoming in a separate set of guidelines.

Structure
There are plenty of different methods for structuring a stylesheet. With the CSS in core, it is important
to retain a high degree of legibility. This enables subsequent contributors to have a clear
understanding of the flow of the document.

Use tabs, not spaces, to indent each property.

Add two blank lines between sections and one blank line between blocks in a section.
Each selector should be on its own line, ending in either a comma or an opening curly brace.
Property-value pairs should be on their own line, with one tab of indentation and an ending
semicolon. The closing brace should be flush left, using the same level of indentation as the
opening selector.
Correct:
1
2
3

#selector-1,
#selector-2,
#selector-3 {
Page 3 of 22

4
5
6

background: #fff;
color: #000;
}

Incorrect:
1
2
3
4
5
6

#selector-1, #selector-2, #selector-3 {

background: #fff;
color: #000;
}
#selector-1 { background: #fff; color: #000; }

Selectors
With specificity, comes great responsibility. Broad selectors allow us to be efficient, yet can have
adverse consequences if not tested. Location-specific selectors can save us time, but will quickly lead
to a cluttered stylesheet. Exercise your best judgement to create selectors that find the right balance
between contributing to the overall style and layout of the DOM.

Similar to the Standards for file names, use lowercase and separate words with hyphens when
naming selectors. Avoid camelcase and underscores.
Use human readable selectors that describe what element(s) they style.
Attribute selectors should use double quotes around values
Refrain from using over-qualified selectors, div.container can simply be stated as .container

Correct:
1
2
3
4
5
6
7

#comment-form {
margin: 1em 0;
}
input[type="text"] {
line-height: 1.1;
}

Incorrect:
1
2
3
4
5

#commentForm { /* Avoid camelcase. */

margin: 0;
}
#comment_form { /* Avoid underscores. */

Page 4 of 22

6
7
8
9
10
11
12
13
14
15
16
17
18
19

margin: 0;
}
div#comment_form { /* Avoid over-qualification. */
margin: 0;
}
#c1-xr { /* What is a c1-xr?! Use a better name. */
margin: 0;
}
input[type=text] { /* Should be [type="text"] */
line-height: 110% /* Also doubly incorrect */
}

Properties
Similar to selectors, properties that are too specific will hinder the flexibility of the design. Less is
more. Make sure you are not repeating styling or introducing fixed dimensions (when a fluid solution
is more acceptable).

Properties should be followed by a colon and a space.

All properties and values should be lowercase, except for font names and vendor-specific
properties.
Use hex code for colors, or rgba() if opacity is needed. Avoid RGB format and uppercase, and
shorten values when possible: #fff instead of #FFFFFF.
Use shorthand (except when overriding styles) for background, border, font, list-style, margin, and
padding values as much as possible. (For a shorthand reference, see CSS Shorthand.)

Property Ordering
Group like properties together, especially if you have a lot of them.
Nacin
Above all else, choose something that is meaningful to you and semantic in some way. Random
ordering is chaos, not poetry. Our choice is logical or grouped ordering, wherein properties are
grouped by meaning and ordered specifically within those groups. The properties within groups are
also strategically ordered to create transitions between sections, such as background directly before
color. The baseline for ordering is:

Display
Positioning
Page 5 of 22

Box model
Colors and Typography
Other
Things that are not yet used in core itself, such as CSS3 animations, may not have a prescribed place
above but likely would fit into one of the above in a logical manner. Just as CSS is evolving, so our
standards will evolve with it.
Top/Right/Bottom/Left (TRBL/trouble) should be the order for any relevant properties (e.g. margin),
much as the order goes in values. Corner specifiers (e.g. border-radius-*-*) should be top-left, topright, bottom-right, bottom-left. This is derived from how shorthand values would be ordered.
Example:
1
2
3
4
5
6
7

#overlay {
position: absolute;
z-index: 1;
padding: 10px;
background: #fff;
color: #777;
}

Example:
1
2
3
4
5
6
7

#overlay {
background: #fff;
color: #777;
padding: 10px;
position: absolute;
z-index: 1;
}

Vendor Prefixes
We use grunt-autoprefixer as a pre-commit tool to easily manage necessary browser prefixes, thus
making the majority of this section moot. For those interested in following that output without using
Grunt, vendor prefixes should go longest (-webkit-) to shortest (unprefixed). All other spacing remains
as per the rest of standards.
1
2
3
4
5

.sample-output {
-webkit-box-shadow: inset 0 0 1px 1px #eee;
-moz-box-shadow: inset 0 0 1px 1px #eee;
box-shadow: inset 0 0 1px 1px #eee;
}
Page 6 of 22

Values
There are numerous ways to input values for properties. Follow the guidelines below to help us retain
a high degree of consistency.

Space before the value, after the colon

Do not pad parentheses with spaces
Always end in a semicolon
Use double quotes rather than single quotes, and only when needed, such as when a font name
has a space.
0 values should not have units unless necessary, such as with transition-duration.
Line height should also be unit-less, unless necessary to be defined as a specific pixel value. This is
more than just a style convention, but is worth mentioning here. More
information:http://meyerweb.com/eric/thoughts/2006/02/08/unitless-line-heights/
Use a leading zero for decimal values, including in rgba().
Multiple comma-separated values for one property should be separated by either a space or a
newline, including within rgba(). Newlines should be used for lengthier multi-part values such as
those for shorthand properties like box-shadow and text-shadow. Each subsequent value after the
first should then be on a new line, indented to the same level as the selector and then spaced over
to left-align with the previous value.

Correct:
1
2
3
4
5
6
7
8
9
10

.class { /* Correct usage of quotes */

background-image: url(images/bg.png);
font-family: "Helvetica Neue", sans-serif;
}
.class { /* Correct usage of zero values */
font-family: Georgia, serif;
text-shadow: 0 -1px 0 rgba(0, 0, 0, 0.5),
0 1px 0 #fff;
}

Incorrect:
1
2
3
4
5
6

.class { /* Avoid missing space and semicolon */

background:#fff
}
.class { /* Avoid adding a unit on a zero value */
margin: 0px 0px 20px 0px;
Page 7 of 22

Media Queries
Media queries allow us to gracefully degrade the DOM for different screen sizes. If you are adding
any, be sure to test above and below the break-point you are targeting.

It is generally advisable to keep media queries grouped by media at the bottom of the stylesheet.
An exception is made for the wp-admin.css file in core, as it is very large and each section
essentially represents a stylesheet of its own. Media queries are therefore added at the bottom
of sections as applicable.
Rule sets for media queries should be indented one level in.

Example:
1
2
3
4

@media all and (max-width: 699px) and (min-width: 520px) {

/* Your selectors */
}

Commenting

Comment, and comment liberally. If there are concerns about file size, utilize minified files and the
SCRIPT_DEBUG constant. Long comments should manually break the line length at 80 characters.
A table of contents should be utilized for longer stylesheets, especially those that are highly
sectioned. Using an index number (1.0, 1.1, 2.0, etc.) aids in searching and jumping to a location.
Comments should be formatted much as PHPDoc is. The CSSDoc standard is not necessarily widely
accepted or used but some aspects of it may be adopted over time. Section/subsection headers
should have newlines before and after. Inline comments should not have empty newlines
separating the comment from the item to which it relates.

For sections and subsections:

1
2
3
4
5
6
7
8

/**
* #.# Section title
*
* Description of section, whether or not it has media queries, etc.
*/
.selector {
float: left;
Page 8 of 22

For inline:
1
2
3
4
5
6

/* This is a comment about this selector */

.another-selector {
position: absolute;
top: 0 !important; /* I should explain why this is so !important */
}

Best Practices
Stylesheets tend to get long in length. Focus slowly gets lost whilst intended goals start repeating and
overlapping. Writing smart code from the outset helps us retain the overview whilst remaining
flexible throughout change.

If you are attempting to fix an issue, attempt to remove code before adding more.
Magic Numbers are unlucky. These are numbers that are used as quick fixes on a one-off basis.
Example: .box { margin-top: 37px }.
DOM will change over time, target the element you want to use as opposed to finding it through
its parents. Example: Use .highlight on the element as opposed to .highlight a (where the selector is
on the parent)
Know when to use the height property. It should be used when you are including outside elements
(such as images). Otherwise use line-height for more flexibility.
Do not restate default property & value combinations (for instance display: block; on block-level
elements).

JavaScript Coding Standards

JavaScript has become a critical component in developing Web-based applications. Standards are
needed for formatting and styling JavaScript code to maintain the same code consistency as the Web
standards provide for core PHP, HTML, and CSS code.
All code in any code-base should look like a single person typed it, no matter how many people
contributed. Principles of Writing Consistent, Idiomatic JavaScript

Page 9 of 22

The JavaScript Coding Standards are adapted from the jQuery JavaScript Style Guide. Our standard
differs from the jQuery guidelines in the following ways:

We use single quotation marks for string declarations.

Case statements are indented within switch blocks.
Function contents are consistently indented, including full-file closure wrappers.
Some whitespace rules differ, for consistency with the PHP coding standards.
jQuerys 100-character hard line limit is encouraged, but not strictly enforced.
Many of the examples below have been adapted directly from the jQuery style guide; these
differences have all been integrated into the examples on this page. Any of the below standards and
examples should be considered best practice for Javascript code, unless explicitly noted as antipatterns.

Code Refactoring
Code refactoring should not be done just because we can. Lead Developer Andrew Nacin
Many parts of the code structure for JavaScript are inconsistent in their style. So we need to be
refactoring it as code evolves.
While the coding standards are important, refactoring older .js files simply to conform to the
standards is not an urgent issue. Whitespace-only patches for older files are strongly discouraged.
All new or updated JavaScript code should be reviewed to ensure it conforms to the standards, and
passes JSHint.

Spacing
Use spaces liberally throughout your code. When in doubt, space it out.
These rules encourage liberal spacing for improved developer readability. The minification process
creates a file that is optimized for browsers to read and process.

Indentation with tabs.

No whitespace at the end of line or on blank lines.
Lines should usually be no longer than 80 characters, and should not exceed 100 (counting tabs as 4
spaces). This is a soft rule, but long lines generally indicate unreadable or disorganized code.
if/else/for/while/try blocks should always use braces, and always go on multiple lines.
Unary special-character operators (e.g., ++, --) must not have space next to their operand.
Any , and ; must not have preceding space.
Page 10 of 22

Any ; used as a statement terminator must be at the end of the line.

Any : after a property name in an object definition must not have preceding space.
The ? and : in a ternary conditional must have space on both sides.
No filler spaces in empty constructs (e.g., {}, [], fn()).
There should be a new line at the end of each file.
Any ! negation operator should have a following space.*
All function bodies are indented by one tab, even if the entire file is wrapped in a closure. *
Spaces may align code within documentation blocks or within a line, but only tabs should be used
at the start of a line.*
*: The JavaScript standards prefer slightly broader whitespace rules than the jQuery style guide. These
deviations are for consistency between the JavaScript files codebase.
Whitespace can easily accumulate at the end of a line avoid this, as trailing whitespace is caught as
an error in JSHint. One way to catch whitespace buildup is enabling visible whitespace characters
within your text editor.
Objects
Object declarations can be made on a single line if they are short (remember the line length
guidelines). When an object declaration is too long to fit on one line, there must be one property per
line. Property names only need to be quoted if they are reserved words or contain special characters:
1
2
3
4
5
6
7
8
9
10
11
12
13

// Preferred
var map = {
ready: 9,
when: 4,
'you are': 15
};
// Acceptable for small objects
var map = { ready: 9, when: 4, 'you are': 15 };
// Bad
var map = { ready: 9,
when: 4, 'you are': 15 };

Arrays and Function Calls

Always include extra spaces around elements and arguments:
1
2

array = [ a, b ];

Page 11 of 22

3
4
5
6
7
8
9

foo( arg );
foo( 'string', object );
foo( options, object[ property ] );
foo( node, 'property', 2 );

Exceptions:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

// For consistency with our PHP standards, do not include a space around
// string literals or integers used as key values in array notation:
prop = object['default'];
firstArrayElement = arr[0];
// Function with a callback, object, or array as the sole argument:
// No space on either side of the argument
foo(function() {
// Do stuff
});
foo({
a: 'alpha',
b: 'beta'
});
foo([
'alpha',
'beta'
]);
// Function with a callback, object, or array as the first argument:
// No space before the first argument
foo(function() {
// Do stuff
}, options );
// Function with a callback, object, or array as the last argument:
// No space after after the last argument
foo( data, function() {
// Do stuff
});

Page 12 of 22

Examples of Good Spacing

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

var i;
if ( condition ) {
doSomething( 'with a string' );
} else if ( otherCondition ) {
otherThing({
key: value,
otherKey: otherValue
});
} else {
somethingElse( true );
}
// This is also done to conform to our PHP standards.
while ( ! condition ) {
iterating++;
}
for ( i = 0; i < 100; i++ ) {
object[ array[ i ] ] = someFn( i );
$( '.container' ).val( array[ i ] );
}
try {
// Expressions
} catch ( e ) {
// Expressions
}

Semicolons
Use them. Never rely on Automatic Semicolon Insertion (ASI).

Page 13 of 22

Indentation and Line Breaks

Indentation and line breaks add readability to complex statements.
Tabs should be used for indentation. Even if the entire file is contained in a closure (i.e., an
immediately invoked function), the contents of that function should be indented by one tab:
1
2
3
4
5
6
7

(function( $ ) {
// Expressions indented
function doSomething() {
// Expressions indented
}
})( jQuery );

Blocks and Curly Braces

if, else, for, while, and try blocks should always use braces, and always go on multiple lines. The
opening brace should be on the same line as the function definition, the conditional, or the loop. The
closing brace should be on the line directly following the last statement of the block.
1
2
3
4
5
6
7
8
9

var a, b, c;
if ( myFunction() ) {
// Expressions
} else if ( ( a && b ) || c ) {
// Expressions
} else {
// Expressions
}

Multi-line Statements
When a statement is too long to fit on one line, line breaks must occur after an operator.
1
2
3
4
5
6

// Bad
var html = '<p>The sum of ' + a + ' and ' + b + ' plus ' + c
+ ' is ' + ( a + b + c );
// Good
var html = '<p>The sum of ' + a + ' and ' + b + ' plus ' + c +
Page 14 of 22

' is ' + ( a + b + c );

Lines should be broken into logical groups if it improves readability, such as splitting each expression
of a ternary operator onto its own line, even if both will fit on a single line.
1
2
3
4
5
6
7

// Acceptable
var baz = ( true === conditionalStatement() ) ? 'thing 1' : 'thing 2';
// Better
var baz = firstCondition( foo ) && secondCondition( bar ) ?
qux( foo, bar ) :
foo;

When a conditional is too long to fit on one line, successive lines must be indented one extra level to
distinguish them from the body.
1
2
3
4

if ( firstCondition() && secondCondition() &&

thirdCondition() ) {
doStuff();
}

Chained Method Calls

When a chain of method calls is too long to fit on one line, there must be one call per line, with the
first call on a separate line from the object the methods are called on. If the method changes the
context, an extra level of indentation must be used.
1
2
3
4
5
6

elements
.addClass( 'foo' )
.children()
.html( 'hello' )
.end()
.appendTo( 'body' );

Assignments and Globals

Declaring Variables With var

Each function should begin with a single comma-delimited var statement that declares any local
variables necessary. If a function does not declare a variable using var, that variable can leak into an
Page 15 of 22

outer scope (which is frequently the global scope, a worst-case scenario), and can unwittingly refer to
and modify that data.
Assignments within the var statement should be listed on individual lines, while declarations can be
grouped on a single line. Any additional lines should be indented with an additional tab. Objects and
functions that occupy more than a handful of lines should be assigned outside of the var statement,
to avoid over-indentation.
1
2
3
4
5
6
7
8
9
10
11

// Good
var k, m, length,
// Indent subsequent lines by one tab
value = 'Sweet Ride';
// Bad
var foo = true;
var bar = false;
var a;
var b;
var c;

Globals
All globals used within a file should be documented at the top of that file. Multiple globals can be
comma-separated.
This example would make passwordStrength an allowed global variable within that file:
1

/* global passwordStrength:true */

The true after passwordStrength means that this global is being defined within this file. If you are
accessing a global which is defined elsewhere, omit :true to designate the global as read-only.
Common Libraries
Backbone, jQuery, Underscore, and the global wp object are all registered as allowed globals in the
root .jshintrc file.
Backbone and Underscore may be accessed directly at any time. jQuery should be accessed
through $ by passing thejQuery object into an anonymous function:
1
2
3

(function( $ ) {
// Expressions
})( jQuery );

Page 16 of 22

This will negate the need to call .noConflict(), or to set $ using another variable.
Files which add to, or modify, the wp object must safely access the global to avoid overwriting
previously set properties:
1
2

// At the top of the file, set "wp" to its existing value (if present)
window.wp = window.wp || {};

Naming Conventions
Variable and function names should be full words, using camel case with a lowercase first letter.
Constructors intended for use with new should have a capital first letter (UpperCamelCase).
Names should be descriptive, but not excessively so. Exceptions are allowed for iterators, such as the
use of i to represent the index in a loop.

Comments
Comments come before the code to which they refer, and should always be preceded by a blank line.
Capitalize the first letter of the comment, and include a period at the end when writing full sentences.
There must be a single space between the comment token (//) and the comment text.
Single line comments:
1
2
3
4

someStatement();
// Explanation of something complex on the next line
$( 'p' ).doSomething();

Multi-line comments should be used for long comments:

1
2
3
4

/*
This is a comment that is long enough to warrant being stretched
over the span of multiple lines.
*/

Inline comments are allowed as an exception when used to annotate special arguments in formal
parameter lists:
1
2
3

function foo( types, selector, data, fn, /* INTERNAL */ one ) {

// Do stuff
}

Page 17 of 22

Equality
Strict equality checks (===) must be used in favor of abstract equality checks (==). The only exception
is when checking for both undefined and null by way of null.
1
2
3
4

// Check for both undefined and null values, for some important reason.
if ( undefOrNull == null ) {
// Expressions
}

Type Checks
These are the preferred ways of checking the type of an object:

String: typeof object === 'string'

Number: typeof object === 'number'
Boolean: typeof object === 'boolean'
Object: typeof object === 'object' or _.isObject( object )
Plain Object: jQuery.isPlainObject( object )
Function: _.isFunction( object) or jQuery.isFunction( object )
Array: _.isArray( object ) or jQuery.isArray( object )
Element: object.nodeType or _.isElement( object )
null: object === null
null or undefined: object == null
undefined:
Global Variables: typeof variable === 'undefined'
Local Variables: variable === undefined
Properties: object.prop === undefined
Any of the above: _.isUndefined( object )
Anywhere Backbone or Underscore are already used, you are encouraged to use Underscore.jss type
checking methods over jQuerys.

Strings
Use single-quotes for string literals:
1

var myStr = 'strings should be contained in single quotes';

Page 18 of 22

When a string contains single quotes, they need to be escaped with a backslash (\):
1
2

// Escape single quotes within strings:

'Note the backslash before the \'single quotes\'';

Switch Statements
The usage of switch statements is generally discouraged, but can be useful when there are a large
number of cases especially when multiple cases can be handled by the same block, or fall-through
logic (the default case) can be leveraged.
When using switch statements:
Use a break for each case other than default. When allowing statements to fall through, note that
explicitly.
Indent case statements one tab within the switch.
1
2
3
4
5
6
7
8
9
10
11
12
13

switch ( event.keyCode ) {
// ENTER and SPACE both trigger x()
case $.ui.keyCode.ENTER:
case $.ui.keyCode.SPACE:
x();
break;
case $.ui.keyCode.ESCAPE:
y();
break;
default:
z();
}

It is not recommended to return a value from within a switch statement: use the case blocks to set
values, then returnthose values at the end.
1
2
3
4
5
6
7
8
9

function getKeyCode( keyCode ) {

var result;
switch ( event.keyCode ) {
case $.ui.keyCode.ENTER:
case $.ui.keyCode.SPACE:
result = 'commit';
break;
case $.ui.keyCode.ESCAPE:
Page 19 of 22

10
11
12
13
14
15
16
17

result = 'exit';
break;
default:
result = 'default';
}
return result;
}

Best Practices

Arrays
Creating arrays in JavaScript should be done using the shorthand [] constructor rather than the new
Array() notation.
1

var myArray = [];

You can initialize an array during construction:

1

var myArray = [ 1, 'My Blog', 2, 'Blog' ];

In JavaScript, associative arrays are defined as objects.

Objects
There are many ways to create objects in JavaScript. Object literal notation, {}, is both the most
performant, and also the easiest to read.
1

var myObj = {};

Object literal notation should be used unless the object requires a specific prototype, in which case
the object should be created by calling a constructor function with new.
1

var myObj = new ConstructorMethod();

Object properties should be accessed via dot notation, unless the key is a variable, a reserved word,
or a string that would not be a valid identifier:
1
2
3
4

prop = object.propertyName;
prop = object[ variableKey ];
prop = object['default'];
prop = object['key-with-hyphens'];
Page 20 of 22

Yoda Conditions
Whenever you are comparing an object to a string, boolean, integer, or other constant or literal, the
variable should always be put on the right hand side, and the constant or literal put on the left.
1
2
3

if ( true === myCondition ) {

// Do stuff
}

A little bizarre, it is, to read. Get used to it, you will.

Iteration
When iterating over a large collection using a for loop, it is recommended to store the loops max
value as a variable rather than re-computing the maximum every time:
1
2
3
4
5
6
7
8
9
10
11
12
13

// Good & Efficient

var i, max;
// getItemCount() gets called once
for ( i = 0, max = getItemCount(); i < max; i++ ) {
// Do stuff
}
// Bad & Potentially Inefficient:
// getItemCount() gets called every time
for ( i = 0; i < getItemCount(); i++ ) {
// Do stuff
}

Underscore.js Collection Functions

Learn and understand Underscores collection and array methods. These functions,
including _.each, _.map, and_.reduce, allow for efficient, readable transformations of large data sets.
Underscore also permits jQuery-style chaining with regular JavaScript objects:
1
2
3

var obj = {
first: 'thing 1',
second: 'thing 2',
Page 21 of 22

4
5
6
7
8
9
10
11
12
13
14
15

third: 'lox'
};
var arr = _.chain( obj )
.keys()
.map(function( key ) {
return key + ' comes ' + obj[ key ];
})
// Exit the chain
.value();
// arr === [ 'first comes thing 1', 'second comes thing 2', 'third comes lox' ]

Iterating Over jQuery Collections

The only time jQuery should be used for iteration is when iterating over a collection of jQuery objects:
1
2
3
4
5

$tabs.each(function( index, element ) {

var $element = $( element );
// Do stuff to $element
});

Never use jQuery to iterate over raw data or vanilla JavaScript objects.

Page 22 of 22