Last active
August 29, 2015 14:12
-
-
Save atmd83/9389003af1ccf0ac3c9f to your computer and use it in GitHub Desktop.
Javascript style guide
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/* Javascript style guide | |
* Use jshint | |
* indent with tabs (that way people can adjust the spacing and retain alignment) | |
* blank lines and white space is a good thing and aids readability. | |
* code CAN have appropriate comments. When using sourcecontroll code shouldnt | |
* be commented out, implement or remove (YAGNI/DRY) | |
* | |
* N.B. These are just MY recomendations for readability, performance and maintainability. | |
* Ultimately consistancy is the main goal in a javascript style guide. | |
* *************************************************************************************** | |
*/ | |
/* SEMI-COLONS and CURLY BRACES | |
* Use them everywhere. Created more maintainable code, aids readability and avoid issues | |
* with minifyers/concatanation/build process etc | |
* Opening curly braces SHOULD be on the same line, having them on a new line DOES cause issues | |
* in certain situation and with some compressors. Best just to avaid altogether | |
* (In other languages it doesnt matter, in javascript it DOES) | |
*/ | |
/* VARIABLES | |
* Variables declared individually | |
* if there is a risk of adding to the global namespace, chained if in a closure/scope. | |
* New lines if asigned and declared, single line if just declared/hoisting optimised | |
*/ | |
var myVar = 1, | |
myOther = 2, | |
myThird = 4; | |
// N.B. declaring as above can create globals (mnyOther and myThird) if not scoped/closured | |
var something, somethingElse, anotherThing; // No risk of globals, only happens with asignments | |
/* Arrays, number, strings, functions and objects should be declared with the literal notation | |
* using the new keyword calls the constuctor using extra resources | |
* and can leed to unexpected behavour | |
* such as var a = new Array(5); // an array of 5 undefined items | |
*/ | |
var myObj = {}, myArray = [], myString = "", myNumber = 0, myFunction = function () {}; | |
/* SPACING | |
* spacing should be used to seperate conditions, brackets and asignment. | |
* This make the code more readable/maintainable | |
*/ | |
if (conditional here) { | |
} else { | |
} | |
function myFunction (someParam, anotherParam) { | |
} | |
//N.B. IF statements can be on a single line (with no brackets) if returning early | |
function something (param) { | |
if (!param) return false; | |
} | |
// Dont use spaces though when calling methods | |
myFunction(); // not myFunction (); | |
// opening braces follow a space, not a new line | |
function someThing | |
{ // Boooooooooo | |
function someThing { // nice work | |
if () | |
{ // hard to read, bloats code | |
if () { // amazeballs | |
// The early return above is the only exception | |
/* FUNCTIONS | |
* If functions can be called in the nomal way i.e someFunction(); then they should | |
* use call() and apply() only when required for readability. | |
* parameters need to be well names, avoid using the arguments array | |
*/ | |
function someFunction () {} | |
var someFunction = function () {} | |
/* | |
* When using functions to create classes/objects ALWAYS use the objects prototype | |
* This avoids each instance of an object having its own copy of the methods | |
* and properies you add | |
*/ | |
var myObject = function () {} | |
myObject.prototype.someMethod = function () {} | |
// all instances share the same someMethod function | |
// Dont do this | |
var myObject = function () { | |
this.someMethod = function () { | |
} | |
} // All instances have their own copy of the someMthod function, using more mem/resources | |
/* GENERAL | |
* USefull tips and suggestions | |
*/ | |
// Avoid try/catch blocks | |
try{ | |
} catch (e) { | |
} | |
/* | |
* try catch bloks can hide issues making debugging harder, | |
* they also mask the underlying issues. | |
* Look more into guard clauses and hexagonal architecture as these remove the need | |
* for most try/catch issues. | |
*/ | |
/* Although you should avoid primitive obsession where possible, there is nothing wrong | |
* using primitive types, dont wrap them up to make the code more 'java' like | |
*/ | |
var PRODUCT_NAME = "someThing"; // perfectly acceptable | |
var product = function (name) { | |
this.name = name; | |
}; // dependant on the situation this is overkill | |
// Quotes. Use double for strings, single for properties and params | |
var myName = "Andrew"; | |
document.getElementById('someThing').style.display = 'block'; | |
// HTML -> <div id='someThing' class='someClass'></div> | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment