Create account

DEV Community

How do YOU debug

Waylon Walker on March 25, 2020

How do YOU debug?

debugger?
print statements?
log files?
sending messages to your phone?
super simple setup?
super complicated setup?

Comment deleted

Waylon Walker • Mar 25 '20

honestly in js, I always console.log, if I want to go deeper, I right-click store as variable and inspect it from the console. I've wanted to setup a debugger before, but it seems like a lot of setup. Am I wrong in thinking that?

ponyjackal • Mar 25 '20

Same here.
I also love to use console.log ))

Waylon Walker • Mar 25 '20

I am with the others so far, print statements cover 95% of my debugging. Most of the time I can trim it down to a very small quick running chunk and a couple of print statements, gives me enough insight.

I would also say that I heavily use the ipython repl which gives me a lot of power to inspect things as I am running things.

I also recently learned about the built in python debugger. I had something buried deep into a pipeline that would only error after running for 10 minutes. Python gives you a very convenient breakpoint() in 3.7+ or import pdb; pdb.set_trace() for python 3.7-. ipython also gives you an incredible magic command to run %debug after an error occurs, to allow you to jump into a debugger right where your last error occurred. Again I am still heavily in the print statement debugging camp.

Spyros Argalias • Mar 25 '20

Front end here so we don't tend to keep logs.

95% of the times I debug the scope is fairly small.

I start with a print statement here and there, which is enough most of the time.
If I need to debug properly, I use the debugger with a breakpoint, where I can trace through the code at particular points and see what's happening and what values are.

Other options:

If serious debugging is needed I kind of do detective work. I think "what could be wrong?" and go on from there using the debugger on things that could be going wrong.
I don't use "binary debugging" but I imagine it would be useful if the scope was quite large.
Git bisect (or manually checking out commits) to find the commit where the bug originated. This is very useful because (with a good commit history) it drastically reduces the scope you have to debug.

Waylon Walker • Mar 25 '20

Good one with git bisect. I didn't even think to categorize that as a debugging technique.

Do you fully setup dev tools in your editor to get a debugger running on the front end? I have never done it, so I wonder what the different levels of setup look like. I imagine there is a quick and dirty use browser dev tools up through setting up everything into your editor.

Spyros Argalias • Mar 25 '20

Yeah I use git bisect rarely, it can be quite good :).

Ah I haven't really done that in a while because the browser (I do web development) has really good debugging tools. I have used an editor debugger before that "latches on" to the browser debugger, but I haven't used that since my last job because I didn't need to. To use the browser debugger you can write debugger in the JavaScript code where the debugger should start, or just use the browser debugger directly which is fully functional.

Other than that I do use debuggers that don't run in the browser, such as for Node.

Ben Halpern • Mar 25 '20

I'm all about the print statements. Can't quite wrap my head around debug tools when I want to work fast.

When totally lost, deleting code until the problem shows up is my process of elimination technique.... Thank god for modern version control.

Waylon Walker • Mar 25 '20

Thank god for modern version control.

Heck yes. Version control is so valuable for a good debug session. Slice away all you want then figure out what you actually changed once its all said and done.

Helder Burato Berto • Mar 25 '20

Commonly in the browser, I debug using chrome inspect and a lot of breakpoints.

Working with React + Redux I use this redux-logger nice middleware to help debug or add my own middleware to Redux, like:

const actionLoggerMiddleware = store => next => action => {
  console.groupCollapsed(action.type);
  console.info('dispatching', action);
  const result = next(action);
  console.log('next state', store.getState());
  console.groupEnd();
  return result;
};

const middlewares = [networkMiddleware, thunk, actionLoggerMiddleware];
const middlewareEnhancer = applyMiddleware(...middlewares);

Note: networkMiddleware and thunk are the middleware that is enabled in the project I'm working at this moment.

When working with React Native I like to use Reactotron and in some cases, I use this simple package called logger.js for add simple logs with emojis with a more visible way :)

Steven Torrence • Mar 26 '20

Pry Rails is a must for me when working with Ruby. Debugger that allows me to stop the code and peek around and test variables. Plus it makes the console format better and with color!

github.com/rweng/pry-rails

bravemaster619 • Mar 25 '20 • Edited

Mostly with print statements and log files.

Find out which function is causing a problem with log files
Copy&paste the function and rename the original function old. e.g. problematic_function_old
Add print statements to the copied one.
Usually I add print statements one by one. And throw an error immediately after the print statement. In this way, I can do some "unit test" inside a function. Reproduce the error but step by step, figuring out from where it goes wrong.
If I'm convinced that the error has been fixed, remove the old function.

OMG, I've been simulating a debugger with print statements. xD
In most cases, I don't use debuggers because they suck!

Waylon Walker • Mar 25 '20

OMG, I've been simulating a debugger with print statements.

🤣

I like the idea of copying the function. For some reason I only do this when developing cli tools, but sometimes I will make a verbose flag, then make a separate print function that does an if versbose fro me and i just call vprint for example.