3 ms·
Oh, and I'll add in a separate comment because it's sort of unrelated. Code structure should have very little to do with how you narrow down failing code. You
by horsawlarway 7y ago
Oh, and I'll add in a separate comment because it's sort of unrelated. Code structure should have very little to do with how you narrow down failing code.
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.
- dragonwriter 7y agoYou 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.
- horsawlarway 7y agoNo, 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".
- hollerith 7y agoSo, 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.