Debugging? What???
Hey folks. I've been programming for about five years now (just as a hobby - no formal schooling). But because I've taught myself everything, I seem to have missed out on one big topic: debugging. I never bothered to learn how to use a debugger.
Now, I have VS 2005, so I definitely HAVE a good debugger (or so I'm told), I just have no idea how to use it. But I've been fine for five years without it, so I'm reluctant to learn now.
I've done some cool things, like this graphing calculator. Not using a debugger has made me good at predicting what my code will do before I run it, so if I ever do learn how to properly debug (instead of using cout<<... or MessageBox(...)) I think I will be a great programmer (because I focus more on writing code that works the first time).
So, is it worth it to learn proper debugging? I always just set my projects to "release mode" and never bother with "debug" mode. I seem to be fine with the way things are now, but will debugging prowess make me a much more efficient programmer?
PS: Another one of my bad habits is cramming everything into one .cpp file (I don't always do this, but it happens too often). If the project starts out small (like the graphing calculator I linked to above), then I never bother to encapsulate parts of it and compartmentalize the program.
Well let's put it like this, all of my colleagues know how to use a debugger. It's not because they're lazy, in fact quite the opposite. We use debuggers because it allows us to fix the problems you *dont* see from the outside looking in. When you start developing more complex software it just isn't enough to be able to write code which compiles and runs without defect - sometimes you will encounter a crash bug and to figure out why it happened you will need to peek around the heap and the stack, cpu registers, disassembly, the call stack, what other threads were running at the time, what other processes were doing .. If you've got this far without learning to use a debugger then well done for sticking with it, but your life is about to get a whole lot easier.
A good programmer (or any professional, really) knows how to use all tools available to him or her. A debugger is a very powerful, important tool to know how to use. And besides, you certainly won't be any worse off for learning how to use a debugger.
If you ever want to work with other people on reasonably sized projects, please don't do this.
Quote:Original post by ouraqt
PS: Another one of my bad habits is cramming everything into one .cpp file (I don't always do this, but it happens too often). If the project starts out small (like the graphing calculator I linked to above), then I never bother to encapsulate parts of it and compartmentalize the program.
If you ever want to work with other people on reasonably sized projects, please don't do this.
Quote:Original post by ouraqt
I've been programming for about five years now (just as a hobby - no formal schooling). But because I've taught myself everything, I seem to have missed out on one big topic: debugging. I never bothered to learn how to use a debugger.
You programmed for 5 years, and you never used a debugger ? You have no idea what you missed. Learn to use it, right now. Seriously, you'll be looking back and wondering how you could ever work without one.
I had to briefly work on a (very small) project without a debugger (kernel mode, fun), and I almost killed myself... I felt like I was developping on a C64 again.
I've been just the same like you: developing personal projects without a debugger for 5 years while at university. My way of debugging was to print text messages on screen and see how far it got (the crash would be after the last message it printen). This simply because there didn't come any debugger with DevC++ and later in linux gdb never really seemed interesting to me because it was text based. My only experience with debugging came from long ago in QBasic, which is a scripting language that has debugger built in its IDE in MS DOS.
However at work I started using the debugger in visual studio at the first day already and it's really simply, (breakpoints, step into, step over, step out, all very straightforward). It's really an advantage that if your program crashes, you automatically go to the code where the crash happened, and that you can place breakpoints to see intermediate values of variables :)
Becoming dependent on that (once you start using a debugger it's hard to go back) quickly made me learn gdb in Linux too for my personal projects, it's all really the same as te debugger in Visual Studio, except you have to manually go to the C++ file and the line number instead of it automatically going to it and placing breakpoints is more clumsy (no simple mouse click like in VS).
5 years I've been working with printing strings from inside the code to sort of debug, but really, using a debugger is much handier and really worth it.
Other tools to consider are a profiler or an advanced debugger/memory leak detector like valgrind (though that one's only for linux though afaik).
[Edited by - Lode on March 3, 2008 7:13:39 AM]
However at work I started using the debugger in visual studio at the first day already and it's really simply, (breakpoints, step into, step over, step out, all very straightforward). It's really an advantage that if your program crashes, you automatically go to the code where the crash happened, and that you can place breakpoints to see intermediate values of variables :)
Becoming dependent on that (once you start using a debugger it's hard to go back) quickly made me learn gdb in Linux too for my personal projects, it's all really the same as te debugger in Visual Studio, except you have to manually go to the C++ file and the line number instead of it automatically going to it and placing breakpoints is more clumsy (no simple mouse click like in VS).
5 years I've been working with printing strings from inside the code to sort of debug, but really, using a debugger is much handier and really worth it.
Other tools to consider are a profiler or an advanced debugger/memory leak detector like valgrind (though that one's only for linux though afaik).
[Edited by - Lode on March 3, 2008 7:13:39 AM]
Quote:Original post by ouraqtSo, is it worth it to learn proper debugging?
Absolutely! The amount of time and headaches a debugger will save you will pay back 1000 fold the time you invest in learning it. Do it now! [wink]
I once worked on a project with a manager that was very against the use of a debugger. Yes, there are crazy people out there. The short of it is that his influence alone made the project more difficult and there were some bugs that were found by some of the developers much later in the project than usual (there's only so much you can do with couts/cerrs). I have no doubt that with the use of a debugger, that things would've ran much more smoothly. Of course, knowing what I know now, I would've disobeyed that order and used a debugger anyway, but at the time I was newer in the industry and didn't know better.
The moral of the story is that it's hard enough to write quality software with a debugger. Without a debugger it's almost infeasible.
Also, as mentioned above, please don't write massive source files. One class per source file, that should be your general rule. If your classes are large, you need to split up things into more smaller classes.
The moral of the story is that it's hard enough to write quality software with a debugger. Without a debugger it's almost infeasible.
Also, as mentioned above, please don't write massive source files. One class per source file, that should be your general rule. If your classes are large, you need to split up things into more smaller classes.
Dang. I guess I better get started.
This whole time I've been using cout for console programs and MessageBox flr\\or GUI programs (another thing that came in handy for real-time output was the title bar text of a window).
Another thing I think would make programming faster would be a GUI editor (I think one comes wiht VC++ 2005? I've used it to make dialogs before).
Usually I only write code that is seen by myself, and although I try to keep it as neat as possible, I never realized how much it piqued people to have it all lumped together. Thanks for the advice, buddies!
This whole time I've been using cout for console programs and MessageBox flr\\or GUI programs (another thing that came in handy for real-time output was the title bar text of a window).
Another thing I think would make programming faster would be a GUI editor (I think one comes wiht VC++ 2005? I've used it to make dialogs before).
Usually I only write code that is seen by myself, and although I try to keep it as neat as possible, I never realized how much it piqued people to have it all lumped together. Thanks for the advice, buddies!
When writing code, you will make mistakes, and a huge part of how efficient you are at producing code that works for both you and for others is how efficiently you're able to find and correct your mistakes (and often the mistakes of others).
This means writing code in such a way that errors are caught before you even get to a debugger. So... use asserts liberally (in "debug" modes, normally), and check as much at compile time as you can get away with.
But also learn how to use a debugger. When something isn't working, you usually don't understand why it isn't working right off the bat. There are a couple methods of figuring it out. A common one is adding extra prints to show the values of variables and state, but often it's superior to just step through the offending code in a debugger and see what's going on.
Debuggers are just an efficiency tool. In a way debugging is a lot like coding in that they're both sorts of puzzles. But debugging is the more frustrating one and you want to avoid it if you can by designing and coding as carefully, simply, and cleanly as you know how.
Oh, and a story: last week I spent around 2 days debugging a problem. The code fix turned out to be changing 3 lines. You'll want to learn to debug... there's a good chance you'll be doing it more than coding in a professional environment.
This means writing code in such a way that errors are caught before you even get to a debugger. So... use asserts liberally (in "debug" modes, normally), and check as much at compile time as you can get away with.
But also learn how to use a debugger. When something isn't working, you usually don't understand why it isn't working right off the bat. There are a couple methods of figuring it out. A common one is adding extra prints to show the values of variables and state, but often it's superior to just step through the offending code in a debugger and see what's going on.
Debuggers are just an efficiency tool. In a way debugging is a lot like coding in that they're both sorts of puzzles. But debugging is the more frustrating one and you want to avoid it if you can by designing and coding as carefully, simply, and cleanly as you know how.
Oh, and a story: last week I spent around 2 days debugging a problem. The code fix turned out to be changing 3 lines. You'll want to learn to debug... there's a good chance you'll be doing it more than coding in a professional environment.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement