7 ms·

> PS. If you happen to be a developer of a static analysis tool: Consider leaving long functions alone, rather then reporting them as suspicious. There are circ

> PS. If you happen to be a developer of a static analysis tool: Consider leaving long functions alone, rather then reporting them as suspicious. There are circumstances where long functions are perfectly legal and desirable. Sure, _there are_ circumstances. They're just extremely rare and their occurrence is dependent on the team as well. So generally, I'd say function length a pretty good proxy for complexity--as long as there are overrides.

dagss 7y ago
I disagree with this. I think something should be a seperate function only if it is (or likely will be) called from several callsites. If you try to not always think about contrived cases while writing code, then this rule can sometimes lead to quite long functions simply from executing steps in sequence ("script"). One can split what is really a long function into several small ones for readability, but if one does so I think one should declare that function within the calling function (in languages that support this), and whether one does that or not is really about as insignificant as tab vs spaces or where one likes to have curly braces. My point is, if a function only has one callsite, and is not likely to get more (incl. test code), then whether to inline that function or write it seperately is a style/formatting issue, not a maintainability issue.
- kaybe 7y ago
  Even if you have a few callsites and just copy-paste the same function it can be readable - I've heard that called un-cooked spaghetti code. Everything is still nicely layed out and can be refactored without too much trouble if you so chose. The problem starts with cooked spaghetti code where everything is all mangled up and references are all over the place.
  - barking 7y ago
    I don't know if I'm buying it or not but I like this cooked/uncooked spaghetti code distinction
- RHSeeger 7y ago
  > I disagree with this. I think something should be a seperate function only if it is (or likely will be) called from several callsites. I disagree. I split out anything that I can describe/test separately. If I need to take a list and 1. Filter it based on custom logic 2. Sort it based on custom logic Then I will generally break the filter and sort out into their own functions even if they're not used anywhere else. Each function can have it's own description and tests.
  - dagss 7y ago
    I understand that many prefer this. My point wasn't really so much mine or your preference -- my point was that it is a question of stylistic preference, not about spaghetti vs not. As you simply describe your own stylistic preference I am not sure if you agree with me about that or not? If you actually write a seperate test for the function then you have two callsites and of course it must be a seperate function.
galangalalgol 7y ago
I prefer long functions for readability. I think it depends on domain. Carmack said something like no longer than 6k and that rule of thumb seems large for business code but apparently it is about right for games. I know the intellisense in visual studio breaks down around line 12k in a single cpp file. I probably shouldn't know that. Making changes in th other half of that file was annoying...
mr_crankypants 7y ago
Personally, yeah, I agree, my belief is that most the really long functions I've encountered have been awful unreadable bug farms. But I still think it's a bad idea for a static analysis rule. Two reasons: 1. Static analysis tools should not generate useless noise. I am already well aware that that function I just edited was 1,000 lines long. If I didn't break it down, it's either because I didn't think doing so would be a good idea, or because I don't perceive that to be a problem in the first place, or because I simply don't care. In any case, there's a 100% chance that I'm going to ignore any advice from the static analysis tool on this one. That means that such a rule is, at best, useless. 2. I'm generally not sure if my feelings about long functions reflect reality. I recently saw a talk about evidence-based software practice where the speaker claimed that nobody's been able to demonstrate a link between average function length and code quality, and not for lack of trying.
- james_s_tayler 7y ago
  I think it's useful if you have a rule at the outset of a project that rejects things longer than X where X is the 99% percentile length of a method. I ran the stats retrospectively on a codebase I once worked on to derive sensible values for max class length and max function length. To be honest, they came out at some fairly sensible values and I would be happy putting a blocker in place to say "if you are doing anything more than this, you shouldn't be". I think it was something like 200 lines for a method and 3 or 4 thousand lines for a class. If you can do it at the outset what you'll find is that the vast majority of the time the rule is never triggered. In the majority of cases that it is triggered, it's trivially easy to break the method up a small amount to be under the limit. It's very, very rare to feel like you're having to break it up unnaturally and it feels very forced, though it happens on the extremely odd occasion. I'm OK with that trade-off. The benefit is you never wind up with the 5k line long methodzilla that someone thinks is a good idea and everyone laments forever. Every code base I've seen has one godzilla method. I'd prefer we avoid godzilla methods at least. You don't need an 18k line class. Nor a 5k line method.
  - mr_crankypants 7y ago
    Yeah. It's not necessarily that I don't think that it's useful to place limits on length. It's more that it's hard for me to imagine a situation where a godzilla method like that sails past code review, but then gets broken up, anyway, because the static analysis tool said, "Oh, hey, getting a little big there." A static analysis tool is best when it's used for catching things that are hard to see. I'd argue that employing it as a substitute for caring about your code is more of a misuse. And that using it as a substitute for a culture of careful, diligent code review is just a special case of that.

dagss 7y ago

I disagree with this. I think something should be a seperate function only if it is (or likely will be) called from several callsites. If you try to not always think about contrived cases while writing code, then this rule can sometimes lead to quite long functions simply from executing steps in sequence ("script"). One can split what is really a long function into several small ones for readability, but if one does so I think one should declare that function within the calling function (in languages that support this), and whether one does that or not is really about as insignificant as tab vs spaces or where one likes to have curly braces. My point is, if a function only has one callsite, and is not likely to get more (incl. test code), then whether to inline that function or write it seperately is a style/formatting issue, not a maintainability issue.

kaybe 7y ago
Even if you have a few callsites and just copy-paste the same function it can be readable - I've heard that called un-cooked spaghetti code. Everything is still nicely layed out and can be refactored without too much trouble if you so chose. The problem starts with cooked spaghetti code where everything is all mangled up and references are all over the place.
- barking 7y ago
  I don't know if I'm buying it or not but I like this cooked/uncooked spaghetti code distinction
RHSeeger 7y ago
> I disagree with this. I think something should be a seperate function only if it is (or likely will be) called from several callsites. I disagree. I split out anything that I can describe/test separately. If I need to take a list and 1. Filter it based on custom logic 2. Sort it based on custom logic Then I will generally break the filter and sort out into their own functions even if they're not used anywhere else. Each function can have it's own description and tests.
- dagss 7y ago
  I understand that many prefer this. My point wasn't really so much mine or your preference -- my point was that it is a question of stylistic preference, not about spaghetti vs not. As you simply describe your own stylistic preference I am not sure if you agree with me about that or not? If you actually write a seperate test for the function then you have two callsites and of course it must be a seperate function.

galangalalgol 7y ago

I prefer long functions for readability. I think it depends on domain. Carmack said something like no longer than 6k and that rule of thumb seems large for business code but apparently it is about right for games. I know the intellisense in visual studio breaks down around line 12k in a single cpp file. I probably shouldn't know that. Making changes in th other half of that file was annoying...

mr_crankypants 7y ago

Personally, yeah, I agree, my belief is that most the really long functions I've encountered have been awful unreadable bug farms. But I still think it's a bad idea for a static analysis rule. Two reasons: 1. Static analysis tools should not generate useless noise. I am already well aware that that function I just edited was 1,000 lines long. If I didn't break it down, it's either because I didn't think doing so would be a good idea, or because I don't perceive that to be a problem in the first place, or because I simply don't care. In any case, there's a 100% chance that I'm going to ignore any advice from the static analysis tool on this one. That means that such a rule is, at best, useless. 2. I'm generally not sure if my feelings about long functions reflect reality. I recently saw a talk about evidence-based software practice where the speaker claimed that nobody's been able to demonstrate a link between average function length and code quality, and not for lack of trying.

james_s_tayler 7y ago
I think it's useful if you have a rule at the outset of a project that rejects things longer than X where X is the 99% percentile length of a method. I ran the stats retrospectively on a codebase I once worked on to derive sensible values for max class length and max function length. To be honest, they came out at some fairly sensible values and I would be happy putting a blocker in place to say "if you are doing anything more than this, you shouldn't be". I think it was something like 200 lines for a method and 3 or 4 thousand lines for a class. If you can do it at the outset what you'll find is that the vast majority of the time the rule is never triggered. In the majority of cases that it is triggered, it's trivially easy to break the method up a small amount to be under the limit. It's very, very rare to feel like you're having to break it up unnaturally and it feels very forced, though it happens on the extremely odd occasion. I'm OK with that trade-off. The benefit is you never wind up with the 5k line long methodzilla that someone thinks is a good idea and everyone laments forever. Every code base I've seen has one godzilla method. I'd prefer we avoid godzilla methods at least. You don't need an 18k line class. Nor a 5k line method.
- mr_crankypants 7y ago
  Yeah. It's not necessarily that I don't think that it's useful to place limits on length. It's more that it's hard for me to imagine a situation where a godzilla method like that sails past code review, but then gets broken up, anyway, because the static analysis tool said, "Oh, hey, getting a little big there." A static analysis tool is best when it's used for catching things that are hard to see. I'd argue that employing it as a substitute for caring about your code is more of a misuse. And that using it as a substitute for a culture of careful, diligent code review is just a special case of that.