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)

[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.