65

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?

dataol
  • 103
ConditionRacer
  • 5,692
  • 53
    Oldschool printf style debugging as far as I know :-) – Andrew Walters Jan 16 '13 at 21:55
  • 25
    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. –  Jan 16 '13 at 22:01
  • 2
    Not that it wouldn't be possible, but I really hope they're recommending vim and not vi... – Drake Clarris Jan 16 '13 at 22:10
  • 7
    command line debugger, (several IDE debuggers are based on them) – ratchet freak Jan 16 '13 at 22:17
  • 16
    Slowly and carefully. – FrustratedWithFormsDesigner Jan 16 '13 at 22:24
  • This is how I roll. At least two windows for logs (web server + application server [+ db]), one window for browser and one window for vim (which has several panes). I usually use a logger instead of printf because when it is time to go to production, it can be turned off in a single location (e.g., set log level = warn) instead of having to worry about commenting out a bunch of printf lines scattered throughout the code. – BryanH Jan 17 '13 at 00:46
  • 1
    I'm mostly JS-focused so Chrom dev tools and Scite 90% of the time but after looking at the way most IDE-spawned server-side code is architected, I've come to the conclusion that IDEs actually cause most of the problems people think of them as solving. Of course, this makes being forced to use them just to navigate a hot mess of a Java or C# codebase all the more frustrating. And why so much effort into hiding/fragmenting/tag-lib obfuscating of HTML while converting as much code into XML as possible? I don't understand this. – Erik Reppen Jan 17 '13 at 01:03
  • 3
    While prints is quite common its use can hide some bugs that are more subtle such as race conditions. – James Jan 17 '13 at 03:03
  • 1
    Gotta say that while integrated debuggers like the one that runs in Visual Studio are huge productivity boosters, from time to time I think it's good to do old-fashioned development with a text editor and command line just for the exercise. For many reasons. – Phil Jan 17 '13 at 14:47
  • 1
    just get valgrind. – tp1 Jan 17 '13 at 16:08
  • 1
    @Andrew or in the case of a bootloader, int 0x10, or CC 10 – Cole Tobin Jan 18 '13 at 22:17
  • @James If those bugs stay hidden with prints, you don't print enough, in the wrong places or using the wrong method. – Mast Jan 16 '19 at 19:22
  • On one project, I debugged using two windows: my editor and an xterm in which the project was constantly running. My code was full of assert statements. I was using a scripting language, and when I had written two or three lines I would save and view the errors scrolling up. Tapa tap and now the errors were gone or different. All projects are different; another one was to debug 50K lines of C++. In that case, valgrind was needed as @tp1 says. – rleir Apr 07 '20 at 15:39

9 Answers9

89

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.

jimwise
  • 7,578
  • 1
  • 30
  • 32
37

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?).

GlenPeterson
  • 14,920
  • 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 05: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. – Engineer2021 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
  • Yes, thinking with a piece of paper or whiteboard or just in your mind is the best way to debug. It often corrects your thinking process. Debugger sometimes is an easy way out which might not solve the original problem as to why bugs happen in your program :) – Nishant May 19 '16 at 07:19
10

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.

Karl Bielefeldt
  • 147,435
  • 1
    +1 The other option of course is to set colour scheme and keybinds on the IDE's editor, and pretend :) –  Jan 17 '13 at 04:08
  • 1
    @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
6

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.

CodexArcanum
  • 3,451
2

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.

Community
  • 1
Drew Marsh
  • 256
  • 4
    could you please explain in more details how does that answer the question asked? – gnat Jan 17 '13 at 06: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
2

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.

Tom Hawtin - tackline
  • 662
  • "It is worth noticing that comprehensive testing displaces debugging." -- I would say reduces, rather than "displaces". There are definite occasions where running code through a debugger is beneficial, even when performing TDD -- e.g. when a test provides a completely unexpected result, finding out exactly where it went wrong can be very useful -- admittedly, unless it's in the small chunk of code you just wrote, that means you've missed an edge case in your previous testing, but that does happen... – Jules May 19 '16 at 16:46
2

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.

Robert Felten
  • 47
  • 3
    "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
  • 1
    It is surprisingly hard to use a debugger for a sufficiently distributed system, but it is (with some imprecision due to clock sync issue) possible to correlate logs. If your software system is composed of binaries running on 100 different machines, logs/"printf debugging" may be easier than using debuggers and trying to keep everything in sufficient lock-step that you're not introducing other problems. – Vatine May 19 '16 at 09:48
2

I don't usually use a debugger, maybe once every couple weeks but it's not the first thing I go to.

The most important tool in my job is so ubiquitous that I almost forgot to mention it--stack traces. Over 90% of the problems I encounter can be solved by examining a stack trace. This tool isn't always very helpful depending on your language, but when they are implemented well by a language they can save you an amazing amount of time.

I guess the second most common way I detect simple problems is that it's probably the code I just changed. I run unit tests quite often so I generally know what I just broke.

For more complex development and debugging I might add some debug or trace level log statements. I consider development problems a good guide to help me place production trace/debug logging information, which leads me to:

You don't always have a debugger handy. In production it might be impossible to run a debugger (Heck, it might be impossible to access production machines except for logs depending on how secure your company is). There are also languages where hooking up a debugger just takes too long or maybe there just aren't good debuggers available.

If you have been coding all along using logic and debug/trace level logging it can simply be the case of examining your excellent log statements (Possibly increasing the log level) to figure out the problem without even accessing the hardware.

Although I think debuggers are a powerful tool, don't let them be the only tool in your toolbox!

Bill K
  • 2,739
1

Agree that best of problems can be solved away from the computer with a pen and paper or just thinking about the problem. This is more helpful than using live debuggers. It often corrects your thinking process.

You can use pudb which is a console based with a simple user interface. You can chose your preferred debugger like pdb or ipdb if you want to enter a REPL and examine in more detail.

Also please check PythonDebuggingTools Wiki for a more comprehensive collection of tools available.

Nishant
  • 575