Mercyhurst UniversityMath DeptDr Williams Home

MIS 370 Client Side Programming

Style and Best Practices Guide

Introduction: Why Code Style Matters

It is absolutely possible to write code that works flawlessly from the user's perspective, but is nearly impossible to read and that does not follow best practices for the language. But if it works, why should it matter?

Following suggested styles and practices will



Indentation and Whitespace


Semicolons are used to end statements in JavaScript. Most interpreters will interpret a new line as the end of a statement as well, which means we can almost always get away with leaving the semicolons out. While we may not see many examples in class where it makes a difference, you will be expected to include semicolons at the end of each statement in your code. One major advantage of this practice is making it easy to "minify" your code - removing all extraneous whitespace, resulting in a much smaller file that is far more efficient for machines to read (but nearly impossible for humans).

String Quotes

Surround quotes with either double or single string. I tend to use single for things like element IDs that rarely involve any other punctuation, and double for strings that may be displayed to the user, as apostrophes are tolerated within double quotes.


New Objects

The new method for array or object declaration should be avoided. There's not much of an issue with it, it's simply considered an obsolete way of creating objects.
// Use this to define an empty array:
var myArray = [];

// rather than new:
var myArray = new Array();


Functions should be assigned to identifiers using either expression style or definition style. There may be times when only one style will work correctly due to scoping issues, so choose wisely.
// expression style:
var giveMeAnA = function () {
	return 'A';

// definition style:
function giveMeAnA() {
	return 'A';
A good, though outdated, discussion on the topic can be found here.

Shorthand Notation

Feel free to use shorthand notation if you know it, though you will not be required to. Be aware that shorthand notation does make for cleaner code, but may be more difficult to read. We'll begin using shorthand notation later in the semester. If you sometimes have trouble following the logic of a code block, you may want to avoid shorthand notation for now, as it obscures what exactly the code achieves.
// This code:
if ( x % 2 === 0 ) {
	var message = "x is even";
else {
	var message = "x is odd";

// can also be written using shorthand notation like this:
var message = ( x % 2 === 0 ) ? "x is even" : "x is odd";


Unless specifically directed within an assignment, NEVER use eval(). When used haphazardly, eval() could leave you or a viewer of your page open to security threats. While it can be used safely, avoid it for this course.

Debugging Functions

Functions intended primarily to be used for debugging purposes, like console.log(), should be removed before your code is considered complete. Clear exceptions include assignments that require console output, but unless such functions are mentioned in the assignment, please remove them before submitting your work.

Efficient Loops

You can have a significantly increase in speed through careful variable definition. For instance, the loop below works as intended, printing the contents of the array to a DOM element with an ID of 'output'.
var myArray = [ 1, 2, 3 ];
for ( var i = 0; i < myArray.length; i++ ) {
	document.getElementById('output').innerHTML += i;
There are two improvements to make here, however. With each loop, we're requiring a calculation of the length of the array. With only 3 items, that's not such a big deal, but larger arrays can cause a delay. We're also forcing a search for the required DOM element in each loop. We can fix both of these issues by declaring a variable for each outside the loop. There are additional lines of code, but it will be much more efficient:
var myArray = [ 1, 2, 3 ];
var arrayLength = myArray.length;
var outputElement = document.getElementById('output');
for ( var i = 0; i < arrayLength; i++ ) {
	outputElement.innerHTML += i;

A Word on Autofix/Autoclean Editors

Many editors come with the ability to "autofix" your code. This might include adding or removing whitespace, adding characters like semicolons, or other alterations performed automatically. While these editors may make some improvements to the appearance of your code, please manually check all changes. You are ultimately responsible for the formatting of the code you submit.


If you have a linter you're happy with, feel free to continue using it. If not, there is an easy to use, free linter called JSLint that allows you to paste your code and check for any possible issues.

NOTE: JSLint will find errors, and you are not expected to meet it's standard on assignments (other than those outlined above). Do not worry about warnings regarding 'for' or single quote strings, for instance. But it is still a great tool to make sure your code is on the right track and even find errors like missing brackets.

Be aware, according to their own site, "JSLint will hurt your feelings. Side effects may include headache, irritability, dizziness, snarkiness, stomach pain, defensiveness, dry mouth, cleaner code, and a reduced error rate."