Re:The 80/24 Rule
by dragonwriter on Friday November 15, 2019 @12:00PM
(#21546464)
You are talking about what is (or is equivalent to) printf-style debugging; if you use an actual debugger, you can step over function calls, you’ve got to do more work manually setting breakpoints to do the equivalent with undifferentiated streams of code in a long function.
So, you add a command to your debugger that lets you step over a "block" (a sequence of statements surrounded by braces -- the analog to Lisp's PROGN and Scheme's BEGIN) and before you debug the undifferentiated stream of many statements, you factor it into a handful of statements -- without introducing any new function names -- some of which are blocks.
Re:The 80/24 Rule
by horsawlarway on Friday November 15, 2019 @12:12PM
(#21546576)
No, what I'm talking about is how to narrow a problem down. The medium you use to accomplish that is flexible.
I'm a little confused as you why you think clicking step-over 20 times to get out of the std::lib is better than just moving the mouse down 20 lines and adding another break.
So again, this feels like we're back at "this is a matter of preference".
You can do a binary search by just shoving some log statements into the application and seeing what prints out (or hell, use the debugger for your toolset). That doesn't change if I have 100 lines in a single method, or 500 lines divided out into 100 different "tiny" methods.
I think it's actually harder when the methods are all split, because again - more paging back and forth in the editor to add the required debugging info.