Hacker News Reader

Comment by danidiaz | Hacker News Reader

On the opposite end, reading long functions can be hard when they mix levels of abstraction, or their lack of abstraction buries the overall logic with details.

If I'm reading a novel, it would be jarring to read "and then he took 45 steps of average length to reach the kitchen" instead of "he went to the kitchen".

View on HN

I guess the real problem is that writing good short functions is hard, so some people might find it better to just write long functions. By good short functions I mean functions that, as you say, don't mix levels of abstraction, use proper names, and follow a consistent pattern so their behavior can be safely assumed most of the time. And sometimes you can't have such a clear view of the problem because it already got too messy at another stage of the process, and you want to murder the system designer plus maybe some of your coworkers too.

Of course, for certain tasks long functions are still reasonable, but they tend to be the exception rather than the rule, and it takes quite some practice to realize.

Best practical advice: do more design and planning on paper.

I’m always much more proud of a good clean function I’ve written than I am a larger, less clean one. The shorter one takes longer to write, and requires more understanding and thought — and it’s usually the second or third pass refactoring the long less clean one, but it’s always satisfying when I get there.

Easier to test usually, too.

Yeah, you just feel you actually got it right.

I'm dealing with functions thousands of lines long with switch/case and if/else statements five or six levels deep, and it really is the wrong abstraction. It's massive 'handle request' functions, with a switch over a 'ok what kind of request, fetch or update or restore from backup?', then a switch over 'ok what data do you want to fetch or update or restore from backup'. That kinda thing.

That's a bad example. A better example - and yes, I'm totally biased - is the main() method for the rebuild I'm working on - it's basically 'read config', 'set up logger', 'set up service x', 'set up service y', 'validate runtime dependencies like files and scripts', 'create & start http server', 'wait for shutdown signal', 'gracefully shut down http server on shutdown signal', etc. All in one place, no need to extract methods in my opinion. That said, it really is not the critical path of the application.

Sounds like something you can refactor into a N dimensional table with "function pointers" for handling each case.

That could blow your instruction cache sky high. Depending on what you're doing, that could be something you want to avoid.

You don't need function pointers. Just call the functions directly. The problem isn't the switch/if, it's the complete lack of structure.

That's where editor folding comes in.

If you can fold a clause and still understand the code, then you can extract function.

Reply on news.ycombinator.com