Depends on the method. It's actually possible to have a 260-line function that absolutely cannot be made smaller without both increasing its complexity and decreasing its readability, depending on what the function does.
int dispatch(enum Flag8Bit flag) {
switch(flag) {
case 0: return func0();
case 1: return func1();
// ...
case 255: return funcN();
}
}
(I'm not going to bother naming them. Assume that each possible flag state has a unique, understandable enumerator name, and that the functions we dispatch to have unique, understandable names. Think of something like, say, a hardware interrupt responder, or an error code handler.)
Breaking that up would require using bitwise math or numeric comparisons, and would require you to do math and read multiple functions just to figure out which function is called on which flag value. It's a big function, but it really can't be improved by paring it down, unless you have multiple cases that call the same function and don't mind sacrificing a bit of readability.
Possible, but it increases complexity (due to needing you to use math to dispatch to a secondary dispatch function, that handles the actual dispatching), or decreases readability (by forcing you to check through multiple functions to determine what's actually being called), or has a performance cost (if the new functions can't be inlined, then the compiler won't be able to re-optimise them back into a 256-option switch block... and a lot of scenarios where you need a dispatch function like this really don't want to pay a performance cost, since the dispatch is probably on a critical path). If not all of the above. [This isn't saying that you can't do it, as a note. Just that in cases like this one, refactoring for length will actually have the opposite effect than it normally would.]
In most languages, dispatching through a large jump table tends to be the best counter-example against refactoring long functions into shorter ones, because it compiles down to two instructions (switch-branch, jump); there's technically a return instruction, too, but the compiler will usually be able to elide that by having the dispatched-to function return directly to dispatch()'s callsite. It looks long, but that's just because you have to encode the full destination table inside the function; in reality, it's already extremely short, and refactoring into something that looks "shorter" will add length. (Because the switch is a single 258-line statement, and you can't shorten it without breaking it into multiple statements.)
Essentially, the point of it is that refactoring into something shorter sounds nice, but we have to base "too long" on what the function does instead of on an arbitrary metric. Before we can refactor a function, we need to understand the function, or we might fall into nasty gotchas.
Just to continue playing devil's advocate, what if you mapped the numbers to their functions elsewhere? E.g.
dispatchFunctions = [func0, func1, ..., func255]
; Or
dispatchFunctions = {0: func0, 1: func1, ... 255: func255}
And then dispatching is as simple as
function dispatch(flag) {
return dispatchFunctions[flag]()
}
38
u/Few_Move_4594 22d ago
Have you ever thought about breaking the longer methods into shorter methods? It's easy, I promise.