25 ms·
That sounds like an argument for learning how hoisting works, not just avoiding it because it's "weird".
by kevincennis 12y ago
That sounds like an argument for learning how hoisting works, not just avoiding it because it's "weird".
- warfangle 12y agoOr 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()).
- couchand 12y agoI'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.