4 ms·
But what about navigating the code by the call stack? I didn't know that GitHub has a way to do that. Or maybe I'm probably coming across as being dumb enough t
by noisy_boy 5mo ago
But what about navigating the code by the call stack? I didn't know that GitHub has a way to do that. Or maybe I'm probably coming across as being dumb enough to be talking about still trying to have a mental model of what calls what.
- r3trohack3r 5mo agoPersonally, I use a debug agent for that. I've never used breakpoint debugging, was always a printf debugger. And now an agent can do that loop for me. Prompt is usually something along the lines of: >I would expect the behavior of this to be [X] - instead I'm observing [Y] And the agent will form hypothesis, place printf statements, compile, and scrape logs on loop - each loop ruling out hypothesis or narrowing down what portion of the code is responsible for the unexpected behavior. It has been able to pin-point the exact line(s) of code responsible every time I've reached for it so far.
- jaggederest 5mo agoFor what it's worth, generally speaking I read all of the code and keep it in my brain - I have some uncommon assets in that regard like a high reading speed and great memory. `git grep` is the other tool I use often. I rarely find that the call stack is the limiting factor, to me, and I suppose I do something similar to what you're talking about but just in my head - I know where a file is referenced via imports, what a function does, and what the flow of control is like.