[jackmott]

Sometimes that is just inherent in the problem. If a a few thousand lines are actually needed to solve the problem, it will be somewhat hard to deal with whether they are all in one big function or broken up into many functions. One option may be marginally less annoying than the other, depending on what you are doing, or preference perhaps.

But sometimes it is just a "Such is life" situation.

[MereInterest]

I think it depends on whether the problem lends itself to abstraction or not. If I have a problem that requires 1000 lines to solve several large system of linear equations, I'm absolutely going to be separating that out. On the other hand, if I have 1000 lines of "if in country A, apply this tax rate", then I'm not going to separate it, because there is no underlying abstraction to use.

[lostcolony]

That's actually one of the more reasonable uses for OO; have an interface that defines 'apply_tax_rate', and a bunch of implementations for each, so you only have a single line in your function (instance).apply_tax_rate. Of course, that leads to your actual implementing code being scattered in different classes, and that can be a pain, too.

If a functional language, I'd prefer each being its own function, with the case matching in a single, standalone file that returns the appropriate function based on whatever. That way you still get just apply_tax_rate(type, amount) in your main calculation function.

[sbov]

You are saying something I highly doubt you want to be saying.

My "problem" is an online store. It is about 75,000 lines of code. It needs all 75,000 to solve the problem. What you are saying is that it would be "somewhat" hard to deal with whether it is all in one big function or many functions.

But in reality, one big function would be incomprehensible. It is vastly easier to deal with broken out into many functions.

[adrianratnapala]

A problem that genuinely takes a few thousand lines to solve doesn't sound "hard to deal with". It sounds just the right size for a module or tool that solves a problem big enough to be non-trivial, but small enough to be solved well.

However you end up solving it, it is way to big for a single function. On the other hand, a moderate bunch of functions can do it nicely -- and at that scale you don't need big complicated object-oriented abstractions other than the external interface itself.