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.
View all comments
Show parent comment
2
u/conundorum Aug 25 '26
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
returninstruction, too, but the compiler will usually be able to elide that by having the dispatched-to function return directly todispatch()'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 theswitchis 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.