4 ms·
Changing code that you don't understand because you "found" the bug with a step through debugger is a recipe for disaster. In those situations (high turnover/fa
by misthop 5y ago
Changing code that you don't understand because you "found" the bug with a step through debugger is a recipe for disaster. In those situations (high turnover/fast moving tech debt accumulation) perhaps no one cares that the code base is becoming unmaintainable, but it isn't a good practice.
- Jtsummers 5y ago> Changing code that you don't understand because you "found" the bug with a step through debugger is a recipe for disaster. I don't get your point, because that's not what I suggested someone should do. I think (on rereading my original comment) my point was the exact opposite: Develop an understanding of the code through the effective use of a debugger: > In fact, the debugger can be a fantastic way to learn the code since the dynamic behavior of a system can often be hard to infer from its static representation (looking at you WPF and XAML, or any project where architecture astronauts went hog wild with certain design patterns). You seem to have inferred something from my comment that I did not say.
- misthop 5y agoIf I did I apologize. I agree that using a debugger can be a good way to understand what a codebase is doing. I think we are on a similar page. Sorry for the miscommunication