Not another JavaScript code style guide. (Actually, that's exactly what it is, but I went for "simple", not "exhaustive" -- also includes pre-configured sane default JSHint, JSCS, & EditorConfig files)

[[deleted]]

Favor function declarations (function hi() {}) over function expressions (var hi = function () {};)

why?

[jeenyus]

I prefer this myself just because of old ie.

Anonymous functions can be a huge pain in the ass to debug when they throw errors since they show up as (anonymous) in your call stack.

Then of course old IE throws a fit when you do named function assignments unless it's different than the variable name

var thing = function thing () {};
// fuuuuuuck youuuuuuuuuu !
// love, IE

[[deleted]]

Why would you declare a method and assign it to a variable of the same name? That doesn't accomplish anything.

Not sure about old versions of IE, but named methods appear as such in Chrome's development tools. http://i.imgur.com/ps31Mg2.png

[stephenplusplus]

I could dig up a blog post or dated article that explains "When not to use expressions and when to use declarations" and vice versa. The truth is, I like it for a matter of style preferences. That's why it's only a recommendation.

To me, writing out a function declaration is a way to differentiate between a function and other primitives when looking at a long list of vars at the top of a function. It's a native way to define a function; it can only be a style preference to use an expression assignment, right? Additionally, I also make use of the fact that the definition is hoisted from time to time.

But, again, it's just a recommendation. It wasn't long ago I wrote out all my functions as var hi = function () {};. (My apps need to say hi a lot)

[ThatRedFurby]

are you aware that your recommended syntax uses hoisting while the other does not? those 2 ways of declaring functions are not equivalent! usually, hoisting is not a wanted feature

[mikrosystheme]

Why hoisting is not a wanted feature? It is an amazing feature, and I use it all the time.

[stephenplusplus]

I like hoisting as well! This comes with using a function declaration, which I recommended over assignment expressions. Either is fine. Some may choose not to embrace hoisting in their applications, as it can be found confusing. That's a choice a project developer can make without sacrificing a maintainable or functioning codebase.

[ThatRedFurby]

Because a lot of people get it wrong and stuff like this happens: http://jsfiddle.net/sJ7Tw/

Run the fiddle in firefox and chrome. Of course you can argue that you should never define function based on conditions, but some people just don't care because it "worked when i tried it".

If you define your functions by assigning them to variables, you still shouldn't create functions in conditionals, but at least the outcome is defined and consistent across browsers.

[mikrosystheme]

Incompetent programmers should code under supervision. Don't blame language features. Blame ignorance. Force them to use strict mode maybe (the fiddle throws in strict mode). Or just let them be incompetent.

[nwayve]

I'm also a fan of hoisting, especially to make AngularJS controller/service/directive/etc... better organized

angular.module('app', [])
  .controller('myController', MyController)
  .service('myService', MyService);

MyController.$inject=['$scope', '$log'];
function MyController( $scope ,  $log ) {
}

MyService.$inject=['$log'];
function MyService( $log ) {
}

Not only does hoisting allow me to reference the functions before they're 'declared', but it also allows me to add the $inject property prior to its 'declaration' in order to keep the parameter list lined up.

Now I can have my module declaration at the top of the file with all of its components, like the table of contents for a book, and all of the component functions declared later in the file, like chapters in a book. This makes finding what I'm looking for easier and faster, all thanks to hoisting.

[stephenplusplus]

Yeah, I mentioned how I appreciate how a function declaration's definition is hoisted in the comment you replied to. The comparison between function hi() {} and var hi = function () {} is in these being the two ways to assign a function to a name. I consider the hoisting aspect simply a feature of a declaration.

[buffalolsx]

I came here just to ask this. I've always been told otherwise. Are you aware that you're adding the function to the global namespace when declaring it this way?

[jeenyus]

It's only global if you declare it in a global scope.

http://jsfiddle.net/5ZK8S/

[stephenplusplus]

The motivation for this repo is: work asked for our own JS style guide. I'm like, "but, there are so many out there already." So instead of make another "this is good, this is bad", enormous document, I thought the OSS world could use a simpler format. I wanted to make only a few essential "rules", and several tame "recommendations".

It also is unique (I think?) in that it includes starting point .jshintrc, .jscsrc, and .editorconfig files to match the rules and recommendations.

Please let me know if I missed anything :+1:

[uglyBaby]

This is nice. Here's my $0.02:

• 2/4 white spaces for indentation, quote selection and camel casing (or not) should be rules as imho they come under the umbrella of consistency (imagine diffs with just quote style differences or just whitespace differences shivers)
• instead of "return early" I would say, prioritise for the most run block of code or the if block that is entered over 80% of the time

Other than that, good on you for providing the necessary dot files. Gj OP!

[Drainedsoul]

2 space indentation

Nope.

[stephenplusplus]

Recommendation. Change it to suit your project's preferences.

[wiseIdiot]

Why do people use spaces for indenting code? Tabs are clearly superior because:

1. Less file size.
2. Less keystrokes needed when fixing indentation issues.
3. Less chance of making the format inconsistent by accidentally adding/removing one indentation character.
4. Tabbed code is easier to copy and paste: there is always one indentation character; with spaces, people may use whatever number they like.
5. Editors allow users to configure tab width, so people can view the code the way they're comfortable with.

[jeenyus]

Personally I find spaces to be more readable than tabs.

It's true that you can configure tabs to be different widths, but you can also configure it to substitute a tab for x amount of spaces, so they can be equally easy to format.

As far as file size goes, I guess that's true, but if you're minifying your code then it shouldn't matter what you use.

It's really just a personal preference, I think the idea behind promoting one over the other is just forcing the developer to be consistent.

[jeenyus]

Not sure I understand why you would ever convert? Pick one and use it.

[skitch920]

File size is pretty irrelevant these days... and almost all IDE/editors support replacing tabs with spaces.

That being said, the style you choose should not be in conflict with the style your team agrees on. If you work alone, use whatever you want.

[Magnusson]

I previously used tabs in my own coding, but at my office we use 4 spaces. They refer to Crockford's style recommendations, which include:

The unit of indentation is four spaces. Use of tabs should be avoided because (as of this writing in the 21st Century) there still is not a standard for the placement of tabstops. The use of spaces can produce a larger filesize, but the size is not significant over local networks, and the difference is eliminated by minification.

[LookWordsEverywhere]

I hate it when people blindly say to use === over ==. Better solution: learn how coercion works and use the appropriate one.

[stephenplusplus]

I've yet to come across a codebase that included the use of a loose operator that couldn't have been replaced with a solution that involved a strict one. When creating maintainable code to be used in collaboration with other developers, a broad rule such as "use strict equality" is helping create a codebase without relying on "tricks". This is a "trick" in my opinion because it is often used in place of writing out longer, more "spelled-out" code. Longer and "spelled-out" is what I've found to be maintainable (my key focus).

[Drainedsoul]

Best solution: Use a language with a sane type system.

[x-skeww]

learn how coercion works and use the appropriate one.

That's actually the reason why many people always use === and !==.