(My) JavaScript Style

There isn't exactly a style standard for JavaScript. Douglas Crockford has a good list of conventions. The Google JavaScript Style Guide is an excellent resource and there's even a styleguide from jQuery that I'm not terribly fond of, especially because they so strongly recommend the use of double quotes over single quotes. However, since it seems that generally there are more standards than there are people using them. And they are almost never exactly what you want you to do as a developer. It's like the wild west. When it comes down to it, there are almost as many ways of styling JS as there are ways to write a function.

By way of example:

var myFunction = function ( parameter ) {
  console.log( parameter );
};
function myFunction ( parameter ) {
  console.log(parameter);
}
var someObject = {
                   myFunction: function( parameter ) {
                                 console.log( parameter );
                               }
                 };
var parameter = 'some value';
( function( parameter ) {
  console.log( parameter );
})();

And so on...

There are so many ways of accomplishing the same tasks in JavaScript that it's almost laughable. JS isn't the only language that's structured in this way, of course, but it's the one I'm going to talk about right now.

Why do your own thing?

The issue I generally have with working with JavaScript (or any other language, really) is readability. I'm actually a big fan of Google's Style Guide, but there are little elements that drive me crazy. I think I'm not alone in this, or maybe I am and none of this post matters, but I think I may have chosen to style my JavaScript in a rather unique way and it works for me.

I've found that since changing the way I write my code I have been better able to work with it and that's a big plus in my book. Code that's readable is great both for yourself as a developer and for anyone else that might need to work with your code in the future too.

Settings

I have taken to writing with a soft tab of 2 spaces and all indents are expanded. While some argue that this is less readable I find that it's much easier to work with, especially to try to fit as much on a line before your column break (in my case, I use 132 characters, not 80).

Comments

Comments are the lifeblood of your code. Without comments, how will anyone ever know what's going on? Even you? The number of times I've come back to a project later and had absolutely no idea how anything was doing anything at all. It's like trying to rebuild a clock made of twizzlers and you just can't stop eating them and there's this parrot... and... well, I don't know. I got lost there. If I'd had some comments that would definitely have helped.

Block Comments:
/**
 * comment content goes here.
 **/
/**
 * comment content goes here.
 * another comment line goes here.
 **/

For functions I use comments like so:

/**
 * @desc describes a function's function.
 * @param [object] $paramName - description of the parameter and origin.
 * @return [bool] - $variableName - describes the return and it's destination.
 **/
Inline Comments:

Inline comments are insanely useful to me, but only when used correctly. I like to sprinkle them in through my methods and logic.

  if ( variable !== value ) {
    functionCall(); // this could be a good place for a comment
  } else if ( anotherVariable === aValue ) {
    // now something else should be commented on
    anotherFunctionCall(); // describe the reason for this.
                           // and if you need another line, it's nice to keep
                           // all of these together.
  }
Brackets & Parentheticals:

For all brackets and parentheticals that have content there's a preceding and trailing space for that content, except when embedded I will collapse the trailing spaces. Also, you will add a preceding space as well.

( 'content', 'more content', ( ( variable === true || variable === 'true' )))
{ name: 'value' }

For brackets containing complex values, new lines are used.

var varName = {
                key: 'value',
                additionalKey: false,
                arrayKey: [
                            'containedValue',
                            'anotherValue',
                            42,
                            {
                              objectKey: 'content',
                              futherKey: 64
                            },
                            'stringOfSorts'
                          ]
                }

Please note that commas come at the end of the listed items.

Variable declarations.

When declaring variables, new objects and arrays and strings, I use a single var declaration and simple notation.

var stringVar = '',
    arrayVar = [],
    objectVar = {},
    booleanVar = false,
    $jquerySelecter = $( '.className' ),
    returnedVar = function( parameter );

This is much more readable then instantiating each type of object, new Array() or new Object() is so much messier than [] and {}. Again, note that I leave commas trailing each item.

if / else / else if

There's something you have to remember when it comes to these statements AUB. That's right, AUB (pronounced owb). Always Use Brackets.

if ( variable !== 'value' ) {
  // do something.
} else if ( variable === 'different value' ) {
  // do soemthing else.
} else {
  // finally do another thing.
}

Fin?

This is more or less an overview of what I do. You should do what works for you and always remember that it's best to follow existing styles in the in which you're working.

It's easier to let Google's Style Guide close up this post :

Parting Words

BE CONSISTENT.

If you're editing code, take a few minutes to look at the code around you and determine its style. If they use spaces around all their arithmetic operators, you should too. If their comments have little boxes of hash marks around them, make your comments have little boxes of hash marks around them too.

The point of having style guidelines is to have a common vocabulary of coding so people can concentrate on what you're saying rather than on how you're saying it. We present global style rules here so people know the vocabulary, but local style is also important. If code you add to a file looks drastically different from the existing code around it, it throws readers out of their rhythm when they go to read it. Avoid this.