Using The Debugger in DevTools
As we begin to deal with larger blocks of code, I wanted to find ways to increase my productivity when it comes to debugging my code. I’ve come to the realization that as a future software engineer, most of my time will probably be spent debugging code instead of actually writing it. So it’s only logical that I give other tools a chance instead of always depending on console.log().
Why do we call it a ‘bug’? 🤔
Before I make a case for using the debugger tool, I wanted to touch on the history behind the term bug.
A bug is referred to as a failure or a flaw in the software program. A bug produces an incorrect or undesired result that deviates from the expected result or behavior. — V2Cloud
The first recorded instance of a “computer bug” dates all the way back to 1947 when Grace Hopper, a pioneer in computer science, traced an error back to a dead moth in the Harvard Mark II. The bug was removed and taped to a log book where it was described as a computer bug.
So yes, the first “computer bug” was a literal bug.
Embracing debuggers
As my code became longer and more complex, I grew tired of depending on console.log to catch my mistakes. I knew there had to be a better way and thanks to my instructor Ix, I learned about using a debugger through Chrome DevTools.
A debugger will quickly help you see a problem as it arises in your code execution rather than having you wait for the final broken output. It’s a way to place checkpoints throughout your code. If the debugger comes across an issue it pauses the program from running while giving you the location of the bug.
Once you’ve sprinkled some debuggers in your JavaScript, open your browser and inspect the page. Navigating into Sources will allow you to see the debugger in action and allow you to continue the execution of your code. This sections shows the file navigator on the left, the source code in the middle and the debugging pane on the right. Here you can resume your debugger, examine breakpoints and even see your call stack broken down by line.
By adding pauses with a debugger statement you can walk through how your code is executed and how it’s affecting the data. It’s a simpler way to examine your code and relieve you from being overwhelmed. Using console.log requires a lot more assumptions and can still leave you with a lot of unanswered questions.