Were you taught debugging

Quote:

---

Originally Posted by Speedo

This is really a general attitude issue towards using computers/technology. For a great many people the train of thought goes something more like "Debug menu? What does this do? Hm, I don't know what it is, better leave it alone - might break something".

---

http://www.xkcd.com/627/

Quote:

---

Originally Posted by Arjay

You need another poll choice - something like:

"Self taught programmer, but is proficient in debugging."

---

I thought about that, but I was more interested to see whether it was taught formally, not having gone that route, being a self-taught coder.

Quote:

---

Originally Posted by JohnW@Wessex

Assuming you learnt programming in a formal situation, did debugging get taught in any significant way?

---

There isn't much to teach about debugging is there? There's no special theory behind it or anything.

It's much better to introduce tools of this kind as a natural part of the laboratory part of courses. For example in some basic programmming course you learn how to handle an editor and a debugger, in an electronics course you learn how to handle an oscilloscope, in a microprocessor course you learn how to handle a logic analyzer, in a biochemistry course you learn how to handle a PCR machine, in a type writing course you learn how to handle a coffee machine, etcetera.

There are examples of cases where an "instrument" merits a course of its own but generally they're best introduced in the situation where they're naturally used. I'd say debuggers fall into this category.

I would even go as far as to say that if the university/college you're considering is offering a course in program debugging you should have second thougths. This is a course you would rather expect at a vocational training centre.

Quote:

---

Originally Posted by nuzzle

There isn't much to teach about debugging is there? There's no special theory behind it or anything.

---

The reason I posted this poll was because there are alot of people posting questions here who, while sometimes having a good grasp of the syntax of C++, often have no idea of the basic techniques available to debug their code.

Quote:

---

attachment process work, how symbols are generated, how to analyze the stack, how to analyze core dumps, memory layout

---

What is that ?

Basic debugging seems like common sense to me. As John pointed out earlier the best way would be for the teacher to explain programming techniques during the class that will lead the programmer into learning how to use the debugger in the laboratory. I think that you could have part of a design course dedicated to error handling (including exception handling) / debugging. Unfortunately, during college I never really had a lot of guidance from the teacher. Then again, I went to school for engineering so computer programming was not really my major. I only really had a couple of classes on HOL programming. If I were a computer science major I would highly expect to take classes where debugging / error handling topics were covered in depth.

Quote:

---

Originally Posted by kempofighter

If I were a computer science major I would highly expect to take classes where debugging / error handling topics were covered in depth.

---

Really, I'd expect that focus more in a software engineering major. Maybe in an introductory CS course.

A CS major is more about learning algorithms and data structures and complexity theory and the like, than about the practicalities of coding. They pretty much assume you're going to figure that out on your own, especially if they aren't having you use an obscure language like Lisp or SML.

I answered no, even though my major in college was Computer Science. They showed us a quick way of building a debugger version in Visual Studio and briefly mentioned that we should not port our programs like that. The major push was toward learning the language itself (as in regards to c/C++/MFC.) So having all that knowledge in itself I would struggle a big time, like pretty much so many posters on this site do, as you have already noticed.

I have to confess though that most of my debugging knowledge came from my previous "hobby". (And I feel really bad about it.) One of my friends back in college introduced me to SoftICE and to ways how to bypass a software registration by disassembling/debugging a program to find out the part where the "fix" had to be made. I know, it's bad, but I was stupid back then. (It was almost 10 years ago.) Now I can use that knowledge to not only safe-guard my own software and software of a company I work for, but it also helps me to better understand the debugging process. Here again, I'm not advocating people to go into hacking someone else's software, it's simply a weird way how I came to it.

It also brings another point (which is, I guess, is an advanced debugging technique). Besides simply using a debugger and being able to place a breakpoint and catch a moment right before the "bug" happens, it is also important to be able to analyze the bug itself. In this case, what happened to be an indispensable asset for me, is the knowledge of the machine code and assembler. The Visual Studio has a less known feature (that is disabled by default) to not only see the source code but to also see a machine code for each line (called Toggle Disassembly, or Ctrl+F11). By seeing the disassembly for each line of code you can easily track down any hidden calls and registry/memory corruption that in a source code would appear as one line. That saved my butt many times.

One more thing I want to add here, is that my way of designing software includes insertion of the ASSERT/VERIFY macros (for MFC) into as many functions/methods in my code as possible. They do checks on any possible erroneous situation, thus, in a way, by using them I'm preventing a possible need for debugging while writing the code. In this case, if an assertion fires I can pretty quickly trace it back to its origins since the whole source code is packed with other assertions (that didn't fire before this one) and thus that in itself provides me with the very moment when glitch occurred.

Really quickly to illustrate what I mean:

Code:

---

//Say somewhere in a code, we need to read 'n' elements in the memory array 'pBuff',
//starting with the index 'i', where 'sz' is the size of an array in array element count
ASSERT(pBuff);    //Simple check that an array pointer is valid
ASSERT(sz >= 0);    //Make sure size is correct
ASSERT(i >= 0 && i < sz);  //Make sure index is valid
ASSERT(n >= 0 && i + n <= sz);    //Make sure number of elements doesn't go out of scope

ASSERT(!IsBadReadPtr(pBuff + i, n * sizeof(*pBuff)));      //Longer check -- use only if you get 'pBuff', 'i' and 'n' from outside of your program. In most cases it's an overkill to use this line

//Reading itself may be necessary to include into an exception-safe block
//All exception handling will stay in a Release build, unlike the ASSERTions.

---

PS.

Quote:

---

Originally Posted by JohnW@Wessex

Am I being a hopeless optimist in thinking that the "What's debugging" count will stay at zero?

---

No so, hah :D

Quote:

---

Originally Posted by JohnW@Wessex

The reason I posted this poll was because there are alot of people posting questions here who, while sometimes having a good grasp of the syntax of C++, often have no idea of the basic techniques available to debug their code.

---

I'm not at all sure a debugger is the right tool for the kinds of problems usually posted at this forum. Simple tracing seems good enougth to me.

What I feel is generally lacking among posters is a program development methology. I was taught something called Stepwise Refinement. Somewhat simplified this means that you start with a small working program. Then you change it in small increments and make sure it still works after each change. In the end you have a big working program without having to debug anything.

Quote:

---

Originally Posted by nuzzle

Somewhat simplified this means that you start with a small working program. Then you change it in small increments and make sure it still works after each change.

---

There are many ways to verify it each time, what do you do?

Quote:

---

Originally Posted by Arjay

There are many ways to verify it each time, what do you do?

---

I put in assertions and traces. The traces are temporary but the assertions stay.

For some types of programming that's good enough. For anything really math-heavy, especially research where the algorithm you're implementing may not be well-understood, I suspect it might not be.

Of course as always, debugging is a combination of approaches used as appropriate. The debugger is only one of many options.

Quote:

---

Originally Posted by Lindley

Of course as always, debugging is a combination of approaches used as appropriate. The debugger is only one of many options.

---

I have a preferred list of debugging techiques. From most preferred to least preferred:

Debugger
Log File
Event log
Trace output
Message box

Blindly trying things hoping it will work is the worse.

Quote:

---

Originally Posted by Lindley

For some types of programming that's good enough. For anything really math-heavy, especially research where the algorithm you're implementing may not be well-understood, I suspect it might not be.

---

Well I don't agree. Stepwise Refinement works whatever you're programming.

I'm not saying you shouldn't use a debugger. I'm saying you should strive for having not to use one.

My list:
Assert
Log File
Debugger
Message box

That's for big projects, for small projects, the log file is at the bottom, but Asserts are always on the top for me.

I use the log file instead of the debugger so that I can program very quickly, once I've got it all written and it's working well, then I go back into the debugger and fine tune it, adding to the stability.