That sounds like an argument for learning how hoisting works, not just avoiding it because it's "weird".

Or limiting when/where you define named functions it's pretty damn silly to declare a named function within an if block within a function call, especially if it has the same name as a function you've defined outside of it.

I tend to limit them to "private" module functions. e.g.,

  "use strict";
  /*global module:true*/

  function add(a, b) {
    return a+b;
  }

  module.exports = {
    sum : function(list) {
      return list.reduce(add, 0);
    }
  };

I don't declare named functions in a scope smaller than the module itself, so I don't really run into the 'weirdness' of hoisting.

Then again, I've moved to commonjs style modules for everything - server side with node, client side with browserify (webpack does weird things with require()).

I'd be in complete agreement if it offered any substantive benefits; however, I've yet to see an example of function-hoisting that can do something regular var-hoisting can't.

It lets you put your functions where you want, for readability, but still be able to use them where they need to be used.

So does regular var-hoisting, which every JS developer already needs to know.