3 ms·

The assertion, which I believed was implied, is that the habit of creating many sub functions will make it more difficult to trace a bug. Imagine having a func

The assertion, which I believed was implied, is that the habit of creating many sub functions will make it more difficult to trace a bug. Imagine having a function with 5 sub functions, and since this is your style, those functions have 5 internal functions. If I want to trace an error, first I have to find it in the main function, then the sub function, and maybe even within its sub functions. Then I have to deal with several different scopes as well. I don’t mind this if a function is a useful abstraction, that is it does something well and is used repeatedly. My gripe is with functions that are written just for the sake of writing functions.

Jestar342 7y ago
> It does not. It makes it exponentially more difficult. is not implicit. That is very much an explicit assertion. I'm simply pointing out that in your pointing out of cargo-cult, you've done the exact same thing of drawing a conclusion with no basis. > Imagine having a function with 5 sub functions, and since this is your style, those functions have 5 internal functions. is unrealistic. There's plenty of room in between "no private functions at all" and "5^n functions for every layer". It's hyperbole and bordering rhetorical. As for tracing bugs in the way you mention - nobody in my sphere of influence has needed to do that in years, at least not on a regular basis. Tests demonstrating IPO are far more valuable and also far more quickly than tracing, narrow the scope of the problem to the point that you'll now be within one small function to read than a potentially much larger one.