3 ms·

Have you worked with 5000 line functions? Just trying to set breakpoints in them at meaningful points is a nightmare. Give me 1000 5-line functions any day - pr

Have you worked with 5000 line functions? Just trying to set breakpoints in them at meaningful points is a nightmare. Give me 1000 5-line functions any day - providing of course they have sensible names (and ideally don't cause unexpected side-effects etc., though when a function is 5-lines long, that's fairly easy to spot; in a 5000-line function, fuhgeddaboudit. My personal guideline is "it should fit on a screen" (at a window/font size you'd normally edit code at - it doesn't vary that much from dev to dev.)

Jensson 4y ago
> and ideally don't cause unexpected side-effects etc., though when a function is 5-lines long, that's fairly easy to spot Not easy to spot side effects if the 5 line function calls 999 other 5 line functions, which you have to do if you replace 1 function with 1000 functions. When people start to arbitrarily break up tightly coupled implementations into tiny functions you will get a much worse mess than if they just kept it as big as it was when they developed it. Small functions are great, but forcing people to write small functions is not great. They are two different things.
- jacquesm 4y ago
  That simply overdoing it. 50 line functions are fine, 100 line functions can be useful. 5000 line functions should be an exception and 5 line functions can be useful if you can still give them a clear name and they end up being either re-used or are internal. If you start exporting 100's of functions you may want to re-evaluate the way you are interfacing your modules.
  - Jensson 4y ago
    The question wasn't "what is the best way to write code" but "is 1000 5 line functions preferable to 1 5000 line function". Of course the best way is somewhere in between, but that wasn't what we were discussing.
    - wizofaus 4y ago
      I'd even say ANY 5000-line function can always be improved by breaking it up into 1000 5-line functions, but it would be rare that would be the ideal way to rewrite it either.
  - speleding 4y ago
    I agree but so much depends on context. This is like arguing a painting should not have too much blue paint. But what if you're painting an ocean? In a programming context: - If the business process you are trying to model clearly has 20 discrete steps is would be silly break them into 4 groups of 5 steps just to hit the ideal function size. - Coming up with a good name for an abstraction in a moderately large program can be very tricky, but a poor name is hurting more than helping. Don't split it if you cannot think of a good name. - If breaking out into a function requires passing in 10 variables then it may become harder to read than simply inlining it. You're probably not abstracting correctly in that case. Etcetera. I've seen so many over-abstractions from junior programmers trying to be "clean" I wonder if these rules of thumb aren't hurting more than helping.
- grogenaut 4y ago
  even worse try debugging it with async or gofuncs or threads... just not doable. You can't easily say "jump into that fork" and it just gets worse from there. Small functions and tons of async and then reflection and polymorphism and it's undebuggable.
- wizofaus 4y ago
  If by "arbitrarily" you mean "at east 4/5 line boundary", perhaps, but in that case it's virtually impossible to give the smaller functions meaningful names. Personally I wouldn't tick a PR with functions more than about 30 lines generally, pretty much the only exception would be something like a simple switch statement that happens to need to deal with 50+ cases, and does so with a single function call for each case* (it may be preferable to do that using a data structure to map input cases to function pointers, but generally that makes code harder to debug too). Arguably that's "forcing" other devs to stick to small functions. I've never seen a 1000+ line function that has anything like any decent sort of unit test coverage, for a start. *) message handlers in raw Win32-apps come to mind
bartread 4y ago
I have, at two different companies, in fact, and 1000-line chubbers at a couple of others. The 5000 line functions weren't great, but they weren't that bad because the code was pretty straightforward, doing one thing after another top to bottom. Over time they all got gradually broken down into smaller functions/methods. (Disclaimer: I was not the original author of any of these.)
userbinator 4y ago
Yes I have, and some even approaching 10kl. It's actually easier when you only have one "dimension" to worry about, and can simply scroll up and down instead of having to jump around between functions, or worse, files. That said, a lot of these huge functions were basically for implementing defined step-by-step processes, and comments delineated the sections as well as loop and condition ends.
- emodendroket 4y ago
  It's not better unless the smaller ones do a poor job of breaking up functionality. One class owning, say, all the code related to making database calls is much better than a bunch of database code strewn throughout unrelated logic.
- UglyToad 4y ago
  I think I have realised after ruining a previous codebase with overeager abstraction. Most code should read like fiction, not a reference book. That is they should read top to bottom with minimal jumping around and information hiding. (Of course not in all cases, YMMV, etc)
emodendroket 4y ago
Hyperbole aside what can actually be said doesn't make great bumper sticker advice: functions shouldn't be too long because that's hard to understand, but they shouldn't be too short either because that's also hard to understand. I think a decent rule of thumb is if it doesn't fit on your screen it might be too long.
barrkel 4y ago
I have. It was mostly a big switch statement, and individual bodies could be read in sequence. It was easy to work with and you could read it by scrolling, instead of jumping around a file.
cush 4y ago
Agree, but picking those 1000 sensible names is usually also very hard, and when people get it wrong and use bad names, sometimes it's worse than nothing.
Seb-C 4y ago
The first thing I do when refactoring spaghetti messes is to remove all useless and counter-productive functions and abstractions, so I can actually get one single, huge function containing all the process. Only from there it becomes possible to have the broad view, reorganize and (re-)factorize the code again properly. So if I had to choose between both, I'd take the 5000 lines function any time, since it makes my job easier.

Jensson 4y ago

> and ideally don't cause unexpected side-effects etc., though when a function is 5-lines long, that's fairly easy to spot Not easy to spot side effects if the 5 line function calls 999 other 5 line functions, which you have to do if you replace 1 function with 1000 functions. When people start to arbitrarily break up tightly coupled implementations into tiny functions you will get a much worse mess than if they just kept it as big as it was when they developed it. Small functions are great, but forcing people to write small functions is not great. They are two different things.

jacquesm 4y ago
That simply overdoing it. 50 line functions are fine, 100 line functions can be useful. 5000 line functions should be an exception and 5 line functions can be useful if you can still give them a clear name and they end up being either re-used or are internal. If you start exporting 100's of functions you may want to re-evaluate the way you are interfacing your modules.
- Jensson 4y ago
  The question wasn't "what is the best way to write code" but "is 1000 5 line functions preferable to 1 5000 line function". Of course the best way is somewhere in between, but that wasn't what we were discussing.
  - wizofaus 4y ago
    I'd even say ANY 5000-line function can always be improved by breaking it up into 1000 5-line functions, but it would be rare that would be the ideal way to rewrite it either.
- speleding 4y ago
  I agree but so much depends on context. This is like arguing a painting should not have too much blue paint. But what if you're painting an ocean? In a programming context: - If the business process you are trying to model clearly has 20 discrete steps is would be silly break them into 4 groups of 5 steps just to hit the ideal function size. - Coming up with a good name for an abstraction in a moderately large program can be very tricky, but a poor name is hurting more than helping. Don't split it if you cannot think of a good name. - If breaking out into a function requires passing in 10 variables then it may become harder to read than simply inlining it. You're probably not abstracting correctly in that case. Etcetera. I've seen so many over-abstractions from junior programmers trying to be "clean" I wonder if these rules of thumb aren't hurting more than helping.
grogenaut 4y ago
even worse try debugging it with async or gofuncs or threads... just not doable. You can't easily say "jump into that fork" and it just gets worse from there. Small functions and tons of async and then reflection and polymorphism and it's undebuggable.
wizofaus 4y ago
If by "arbitrarily" you mean "at east 4/5 line boundary", perhaps, but in that case it's virtually impossible to give the smaller functions meaningful names. Personally I wouldn't tick a PR with functions more than about 30 lines generally, pretty much the only exception would be something like a simple switch statement that happens to need to deal with 50+ cases, and does so with a single function call for each case* (it may be preferable to do that using a data structure to map input cases to function pointers, but generally that makes code harder to debug too). Arguably that's "forcing" other devs to stick to small functions. I've never seen a 1000+ line function that has anything like any decent sort of unit test coverage, for a start. *) message handlers in raw Win32-apps come to mind

bartread 4y ago

I have, at two different companies, in fact, and 1000-line chubbers at a couple of others. The 5000 line functions weren't great, but they weren't that bad because the code was pretty straightforward, doing one thing after another top to bottom. Over time they all got gradually broken down into smaller functions/methods. (Disclaimer: I was not the original author of any of these.)

userbinator 4y ago

Yes I have, and some even approaching 10kl. It's actually easier when you only have one "dimension" to worry about, and can simply scroll up and down instead of having to jump around between functions, or worse, files. That said, a lot of these huge functions were basically for implementing defined step-by-step processes, and comments delineated the sections as well as loop and condition ends.

emodendroket 4y ago
It's not better unless the smaller ones do a poor job of breaking up functionality. One class owning, say, all the code related to making database calls is much better than a bunch of database code strewn throughout unrelated logic.
UglyToad 4y ago
I think I have realised after ruining a previous codebase with overeager abstraction. Most code should read like fiction, not a reference book. That is they should read top to bottom with minimal jumping around and information hiding. (Of course not in all cases, YMMV, etc)

emodendroket 4y ago

Hyperbole aside what can actually be said doesn't make great bumper sticker advice: functions shouldn't be too long because that's hard to understand, but they shouldn't be too short either because that's also hard to understand. I think a decent rule of thumb is if it doesn't fit on your screen it might be too long.

barrkel 4y ago

I have. It was mostly a big switch statement, and individual bodies could be read in sequence. It was easy to work with and you could read it by scrolling, instead of jumping around a file.

cush 4y ago

Agree, but picking those 1000 sensible names is usually also very hard, and when people get it wrong and use bad names, sometimes it's worse than nothing.

Seb-C 4y ago

The first thing I do when refactoring spaghetti messes is to remove all useless and counter-productive functions and abstractions, so I can actually get one single, huge function containing all the process. Only from there it becomes possible to have the broad view, reorganize and (re-)factorize the code again properly. So if I had to choose between both, I'd take the 5000 lines function any time, since it makes my job easier.