My software engineering journey through debugging…
I hate bugs and now that I’m embarking on this new tech career, I’ve come across a whole new category of bugs and there’s something that exists to get rid of them! I give you the debugger!! But first I’d like to discuss the first debugging tool I was introduced to. At the beginning of software engineering school, I was introduced to binding.pry which is also a really good testing tool to look through your code when using Ruby. Watching my instructors easily navigate through this powerful tool was pretty intimidating but to be honest this whole journey has been very intimidating. Eventually I stopped being scared of things I didn’t understand and got really comfortable using binding.pry, but that comfortability was short lived once I moved into Javascript.
Everything about Javascript was stressing me out but then I got introduced to this crazy little tool called debugger and once I saw it in action and all the text, lines, symbols, I immediately closed it and stuck with the trusty console.log(). It wasn’t until my amazing mentor James who I’ve mentioned previously is a JS extraordinaire gave me a mini tutorial on how to use the debugger and navigate through all the helpful things it gives me access to. So enough babble, let’s dive into debugger.
The debugger keyword stops the execution of JavaScript, and calls (if available) the debugging function. If no debugging is available, the debugger statement has no effect. All modern browsers have a built-in JavaScript debugger. When the browser loads a page, the JavaScript code is executed until a breakpoint is met. At this point the execution is stopped and you can inspect all about your running program. You can check the variables values, and resume the execution of the program one line at a time. Console.log() was the first testing tool I was introduced to when starting Javascript. The console.log() method may get the job done, but breakpoints can get it done faster. A breakpoint lets you pause your code in the middle of its execution, and examine all values at that moment in time. Breakpoints have a few advantages over the console.log() method:
- With console.log(), you need to manually open the source code, find the relevant code, insert the console.log() statements, and then reload the page in order to see the messages in the Console. With breakpoints, you can pause on the relevant code without even knowing how the code is structured.
- In your console.log() statements you need to explicitly specify each value that you want to inspect. With breakpoints, DevTools shows you the values of all variables at that moment in time. Sometimes there are variables affecting your code that you're not even aware of.
In short, breakpoints can help you find and fix bugs faster than the console.log() method.
Starting from the left, the first is in blue, clicking it resumes the normal script execution. The second button is step over, and it resumes execution until the next line, and stops again. The next button performs a step into operation: it allows you to go into the function being executed and letting you see the details of it. Step out is the opposite: goes back to the outer function calling this one. These are the main ways to control the flow during debugging.
The Scope pane is only populated when a script is paused. While your page is running, the Scope pane is empty. The Scope pane shows you properties defined at the local and global levels. If a property has a carat icon next to it, it means that it’s an object. Click on the carat icon to expand the object and view its properties.
Although it isn’t clear…here’s a gif that shows all the things you have access to in your debugger. Below I’ve posted a clearer picture.
As I used the debugger more frequently, I’m becoming more and more comfortable with navigating through it. There’s so many things available in the debugger. Here is a helpful resource with more detailed information about the debugger. Happy programming !!
