For me this question REALLY depends on what it's doing. Breaking it into functions introduces overhead -- the push of the current address to the stack, push of any parameters or pointers to parameters to the stack, the far call, the popping of all that off the stack, and that's assuming a compiled language. Interpreted (and/or loosely typed) can often be worse if they do things like "locking" to prevent mutability or transformation by type.

You have to weigh performance against code clarity, but really if you're not re-using any of it I would just comment each block and make DAMNED sure you've got your indentation consistent. Remember, whitespace is your FRIEND.

Though I kind-of worry when people call 100 lines a "long function". Probably because I've written code in assembly, where 1000 lines without a single call or non-conditional jump is the norm.

That said, I would look long and hard at it to try and figure out if there's an easier/faster/smaller way... but then SO many people's codebases these days seem to use ten times the code I would to do the same job. OR WORSE rely on megabytes of frameworks to have written the same amount of code or more as I'd have had WITHOUT the framework involved.

But what do I know? I'm the nut who's been doing this on collections in JS for two decades:

for (var i = 0, element; element = collection[i]; i++) {


Reply to this…

(4 answers) Take me to the question