
Ask HN: How do you debug code? - questionr
For a given algorithm, I find myself placing debug logs all over to print values of variables.<p>I even find this quicker than using breakpoints.
======
maramono
It depends on the difficulty of the bug(s) that need to be localized and
fixed.

I use a wide range of techniques from simple printf's all the way to a full-
blown methodology that has not failed, especially when dealing with coupled
bugs or those caused by concurrency issues, hardware and such.

I wrote about my methodology here: [http://ortask.com/wp-
content/uploads/fault_localization_impr...](http://ortask.com/wp-
content/uploads/fault_localization_improved_testing-Non_ACM.pdf)

------
de4sher
Though I'm a big fan of debugging, and one of my specialties is debugging
_everything_ , I'd also like to point out that writing unit tests is also a
very good way to "debug".

2 good things come out of unit tests:

1\. You'll decrease the chances of having to debug that code again 2\. You'll
learn how to write code that needs less debugging.

Now to adress your question directly, I have developed a few techniques of
debugging, which come in quite useful.

1\. Going directly to the problem. Example 1: you're debugging some database
problems -> put a breakpoint in the library that's interfacing with the
database. Example 2: Some object has some unexpected property -> put a
breakpoint at the point when that property is set. Example 3: you're receiving
weird http requests -> put a breakpoint as close as you can to the code giving
you the request.

2\. Conditional breakpoints. Some IDEs have this feature build in. If not, you
can just write code around that. All you have to do is write a conditional
statement with the condition you expect, and if it will evaluate to True, put
a breakpoint inside this condition - there you have it, simple conditional
breakpointing (helps with loops and other scenarios).

3\. Write code that minimizes state change. I know I'm being preachy again,
but the worst bugs I encountered all revolved around objects being changed by
code in extremely unexpected places. Don't do that! Think by default never to
modify objects once created, and only stray from this rule when the
alternative becomes ridiculous (e.g. when you have to write a lot of really
complicated code which nobody will understand)

------
_RPM
I usually will look at the input, and then look at my output. If it's not what
I expect, I look at the code. Then I'll discover something usually. It's hard
to articulate how I do it. I couldn't pass one of those hacker rank style
challenges for 2 or 3 companies this year out of the box, but I think I can
debug code pretty well.

------
malux85
For 'shallow' bugs, printing / logging - solves problem 90% of time.

Deeper bugs use the IDE, breakpoints and debugger, goto definition and call
stack examination solve the other 10%

Some tips for production: Put logging calls in at critical points -- e.g.
initialisation of interfaces log input and output shapes (I work in mostly in
vectors), DEBUG level logging, which is more verbose, can log the shape of
incoming vectors to help with sanitation efforts.

------
veddox
Yes, debug logs are my usual m.o. too. In general I follow the divide-and-
conquer approach for localizing the source of a bug - it works well for > 95%
of bugs.

If you're using an interpreted language, a REPL is brilliant for debugging
individual functions (I use this mostly with Lisp, but also to some extent
with Python).

Disclaimer: I'm not a professional dev...

