rule proposal: function declarations must go after the rest of the code about standard HOT 10 CLOSED

Whoa, I actually think I read this blog post way before I ever internet-met you. I didn't realize you wrote it.

I agree with the thrust of the proposal. Would you say it's always desirable to declare functions after they're used?

Do you know if there's a jshint or jscs option for this rule? (That's what's currenly used internally.)

from standard.

Cheers :)

I don't think there is a jshint rule for it. Never used jscs. I do in fact think it's always desirable to declare functions after they're used. I think it keeps things sane when there's a lot of async going on.

from standard.

Would you say it's always desirable to declare functions after they're used?

I'd avoid the absolute here. While this does definitely cleanup callback hell, I'm not sure that it makes sense to make it a rule in this app. PS, love the idea of this app.

from standard.

semi-related, all pathological cases of hoisting I could think of: https://gist.github.com/maxogden/4bed247d9852de93c94c

from standard.

IMO this is too opinionated for standard.

from standard.

@andrewrk your blog post only ever addresses the reasons for non-anonymous functions. What was your reasoning for putting them after?

IMHO I believe the opposite, all function declarations should go before the code that uses it; as I parse top down, not bottom up. C style?

At best, as @mafintosh said.

As for top down, jshint: "latedef": true

from standard.

This is actually a style I prefer, but there's no way to enforce it with jshint, jscs, or eslint as far as I'm aware. Also, it's a bit too aggressive to add to standard.

I'm going to close this issue, but feel free to continue discussion.

from standard.

Aggressive eh? When I saw that this project enforces single quotes I thought to myself, "nice, this is super aggressive. I have another aggressive rule to add to that." :-)

from standard.

@feross could add a --ferosscious option?

from standard.

@andrewrk Heh, nice! I'm open to reconsider this when/if one of the listed linters supports detecting this condition.

@dcousens lol. but seriously, NO OPTIONS! ;)

from standard.