5 ms·

If you have _no idea_ where a bug could come from in your code You should spend the time understanding your codebase before you even begin debugging. At the ver

If you have _no idea_ where a bug could come from in your code You should spend the time understanding your codebase before you even begin debugging. At the very least you need to be able to reproduce your bug to reliably fix it. How can you have no idea where a bug is happening if you can trigger the error in a code path? EDIT: I don't want to go so far as to say that your example can never happen, but I can't believe there is any domain where it is the norm

Jtsummers 5y ago
Ever inherited a 500k+ SLOC program with piss poor documentation that you can't rewrite (at least not within the needed timeframe)? Or worked in an office that, on some projects if not overall, experienced high turnover (due to promotions, internal movement, quitting, etc.)? It's very easy to end up with a project in a state where no one actually knows most of the code. A debugger shines here. 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).
- 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 ago
      If 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
mohaine 5y ago
Some issues give you roughly zero feedback. If your error doesn't give you a usable stack trace this about the only option although it isn't probably ever the norm. But the key here is that it works with debugging/logging, even when the error is only a low probability issue the only shows up randomly in production. Debuggers are of no use in this case.
- misthop 5y ago
  Sure. I'm not arguing using a debugger if that is what you prefer. I'm saying that to have no clue where in your code base an issue is cropping up, like _0_ idea, says to me one should spend some time understanding the code before any type of debugging.

Jtsummers 5y ago

Ever inherited a 500k+ SLOC program with piss poor documentation that you can't rewrite (at least not within the needed timeframe)? Or worked in an office that, on some projects if not overall, experienced high turnover (due to promotions, internal movement, quitting, etc.)? It's very easy to end up with a project in a state where no one actually knows most of the code. A debugger shines here. 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).

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 ago
    If 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

mohaine 5y ago

Some issues give you roughly zero feedback. If your error doesn't give you a usable stack trace this about the only option although it isn't probably ever the norm. But the key here is that it works with debugging/logging, even when the error is only a low probability issue the only shows up randomly in production. Debuggers are of no use in this case.

misthop 5y ago
Sure. I'm not arguing using a debugger if that is what you prefer. I'm saying that to have no clue where in your code base an issue is cropping up, like _0_ idea, says to me one should spend some time understanding the code before any type of debugging.