Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Every time I look for an IDE (currently i'm tinkering with Go), I find a thread full of people recommending Vi, Emacs, Notepad++ etc.

I've never done any development outside of an IDE; I guess I've been spoiled. How do you debug without an IDE? Are you limited to just logging?

share|improve this question
45  
Oldschool printf style debugging as far as I know :-) –  Andrew Walters Jan 16 '13 at 21:55
21  
In the days before IDEs, we used debuggers that either attached to a running process or wrapped the process to allow stepping or introspection of the program state. (gdb, perl -d, etc...) The integration of debuggers into IDEs makes it convenient, but they do exist separately. Failing debuggers, logging... just make sure the logging doesn't change the state of the program for when it is taken back out and reintroduce the bug you were trying to find. –  MichaelT Jan 16 '13 at 22:01
6  
command line debugger, (several IDE debuggers are based on them) –  ratchet freak Jan 16 '13 at 22:17
11  
Slowly and carefully. –  FrustratedWithFormsDesigner Jan 16 '13 at 22:24
2  
While prints is quite common its use can hide some bugs that are more subtle such as race conditions. –  James Jan 17 '13 at 3:03

7 Answers 7

up vote 79 down vote accepted

By using a debugger. For the most part, this is also what an IDE does behind the scenes -- it just wraps the experience in a GUI.

On Unix, one of the most commonly used debuggers is GNU gdb, which has largely supplanted the earlier Unix debuggers such as dbx.

To get an idea of what debugging looks like / feels like from the command line, you can look at the gdb manual.

As in other areas, using a debugger from the command line requires learning a syntax and a set of commands, but brings with it a lot of flexibility and scriptability. On the other hand, if you are already comfortable working in an editor such as vim or emacs, you may find that your favorite editor has a plug in for your favorite debugger.

share|improve this answer
15  
+1 for "By using a debugger". The I in IDE stands for "Integrated" :) –  joshin4colours Jan 17 '13 at 1:12
1  
If you write in Python, pdb is actually better than any IDE debugger that I've found. –  syrion Jan 17 '13 at 2:28
1  
@syrion And ipdb is better than that ;) –  Izkata Jan 17 '13 at 14:40
    
Excellent -- I didn't know that existed, Izkata. Thanks. –  syrion Jan 17 '13 at 15:06
    
@joshin4colours integrated != collection, no? –  Cole Johnson Jan 18 '13 at 22:19

I used a debugger for several years while I was writing graphics drivers. I had a second computer that ran the debugger against the first one (because the screen in the primary computer wouldn't work when the graphics driver was broken). It was critical to be able to stop the code and step to the point where I hung the hardware so I'd know what was happening.

For purely software problems, I find that thinking about the problem and testing the system to learn more about the problem is much more useful than stepping through code line by line. With print statements, I have a list of everything that happened at the command line or log file that I can look at and reconstruct what happened, going backwards and forwards more easily than I ever could with a debugger.

The hardest bugs are usually solved by understanding the problem away from the computer. Sometimes with a piece of paper or whiteboard, and sometimes the answer reveals itself while I'm doing something else. The trickiest bugs are solved by looking carefully at the code like playing Where's Waldo. All the rest seem easiest with print statements, or logging statements.

Different people have different styles, and different styles are better for different tasks. Print statements are not necessarily a step down from a debugger. Depending on what you are doing, they can even be better. Especially in a language that doesn't have a native debugger (does Go?).

share|improve this answer
7  
This. Absolutely this. I find, that at least for me, problems tend to be logic errors or interactions that a debugger wouldn't make any more apparent. You have to understand why something is going wrong, not just what. –  Fake Name Jan 17 '13 at 5:41
2  
+1 entirely for going backwards. I often have the experience: "Hey - waittaminute, this isn't the right value! How did this become this?", and have to go back and forth in the output while reading the code. Debuggers are bad at backwards. –  Izkata Jan 17 '13 at 14:43
    
yea, gdb is good for examining dumped core, but in situations like that, I found that gratuitous use of print statements really helped. –  staticx Jan 17 '13 at 19:01
    
Debuggers are usefull but ephemeral. With a good logging framework I find I can build-up my debugging session. Use the debugger to help understand the situation, complement with print statements to make the debugging session permanent. I find that with time I sue the debugger less and less and become more and more productive –  Newtopian Jan 18 '13 at 16:15

Some people use gdb at the command line, or a plugin. There are also standalone GUI front ends to gdb, like DDD. Depending on your language, there are language-specific standalone debugger GUIs, like Winpdb for python, or jswat for java. Because these projects focus only on debugging, they are often superior to integrated debuggers.

The other dirty little secret about IDEs is all of them worth their salt let you specify a custom editor, so you can use parts of the IDE for certain tasks, but use a decent editor for editing. It's not uncommon to only fire up an IDE to use its debugger, especially if that's what your colleagues all use.

share|improve this answer
1  
+1 The other option of course is to set colour scheme and keybinds on the IDE's editor, and pretend :) –  darvids0n Jan 17 '13 at 4:08
    
@darvids0n, I have been using IDEs for something over twenty years, and I have YET to find one with an editor that even begins to hint at thinking about maybe possibly someday hinting that it might sometime next century think about trying to begin to try to hold a candle to GNU Emacs. –  John R. Strohm Jan 17 '13 at 20:20

Some languages offer a REPL - that is, you can write and execute code line by line as you write it, which can be a first step in verifying a piece of code. Many of these also offer debugging facilities. The GHC for Haskell comes with GHCi which can be used to interactively debug a program in the command line, similar to how an IDE would do.

share|improve this answer

I don't understand why there is an aversion to debugging with the use of printf statements. There was a time when it took too long to recompile and link a program, but today it takes just seconds. I find it very easy to debug using cout, printf, qDebug(), etc. type of output. Printf statements give you a running history of everything the program did, that you can analyze after the fact, whereas running in the debugger causes you to have to manually remember the flow of the program as it runs. With printf's, you can convert the value of variables to specific units, display them in hex, decimal, whatever. The printf statements can list the names of the routines and variables, and line numbers as well. You can list only certain array elements depending on other variables. You can follow indirections. You can control the output very easily, put in counters, only print certain times through a loop, add and remove print statements as you debug, have different levels of debugging output, write to files, etc. It's much easier to see the history of your program written to a file than to try to remember all the places you stepped through manually, and maybe have to write down the contents of variables as they change through time, in order to discover what the program has done. And finally, with printf statements you can leave them in permanently, to be turned on and off, for future debugging.

share|improve this answer
1  
"There was a time when it took too long to recompile and link a program, but today it takes just seconds". Depends on your language and size of the project. If I change a header file in my current project, it will take around 65 minutes to rebuild on a 32-CPU machine with 256GB RAM (I am not kidding) –  Nemanja Trifunovic Jan 18 '13 at 16:32
    
People don't have "aversions" to debugging with print statements, they just prefer a debugger. I know a lot more "printf people" who never use debuggers than "debugger people" who never debug using printfs. –  Karl Bielefeldt Jan 18 '13 at 20:48

jimwise answered the question quite well, but I thought I should add that, should you choose to work without a full IDE, the Microsoft provided command line debugger for Windows is called CDB. CDB comes with several other tools, including WinDBG which is the GUI equivalent, when you download the Windows SDK.

share|improve this answer
4  
could you please explain in more details how does that answer the question asked? –  gnat Jan 17 '13 at 6:49
    
You're right, by itself it does not answer the question. I felt that @jimwise's answer was a good answer to the question, but didn't include any information on where to find a command line debugger for Windows. So I figured I'd tack on an additional answer for those that come across this and are wondering how to do it on Windows. I will update my answer to say as much. –  Drew Marsh Jan 18 '13 at 21:58

There's no reason why you can't use the debugger in an IDE alongside a standalone text editor. I used to use !Zap to edit, JBuilder to debug on another machine, and a fileserver in the basement. Traditionally debuggers were standalone programs without dragging along an IDE, and that works too.

It is worth noticing that comprehensive testing displaces debugging. It is worthwhile considering a reported bug to be a bug in your testing rather than in your code.

There's also printf. It can be useful to create a large amount of "logging" and search through it, rather than stopping for every line. I find particularly useful if you can modify library classes that you wouldn't be able to modify in production, for instance using -Xbootclasspath/p: to hack Java library classes.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.