what is debugging?

w

Hello Folks,

Firstly, we need to understand what is bug, before understanding debugging.

A bug refers to an error, fault or flaw in any computer program or a hardware system. It produces unexpected results or causes a system to behave unexpectedly.

If I were to sum up my programming career into two hard truths, they will be following.

  • Anything that can possibly go wrong, will go wrong.
  • Code smells.

And the only skill that is required to counteract these bitter realities is debugging.

Yes, Debugging. No one ( almost no one! ) starts off programming with a love for debugging. Instead, it’s often a source of frustration and dread. How many hours am I going to waste fixing this bug?, a lot of wonder. We’d rather go back to building cool stuff. (Because who doesn’t like building cool stuff?)

Yet it’s hard to find a developer that we admire that doesn’t consider debugging important. That’s because they know that it’s an invaluable source of growth for them. There are few situations that will test your abilities as a developer to the extent that debugging will.

The real problem with debugging is that it is not amenable to a time box. You can timebox almost any activity in programming from design to development. But debugging is a different kind of fish altogether. With a debugging session an hour, a day, or even a week may come and go and you are no closer to finding and fixing the problem.

That’s why you should start approaching debugging as a learning opportunity. Sure the pain will still be there but you keep it under control by doing it the right way.

Here, are five debugging tips for every developer should know.

  • Come up with a hypothesis and test it, come up with another one and test it.
  • Reproduce the bug locally (if it’s convenient).
  • Read the source code carefully.
  • Use print statements effectively.
  • Use a debugging effectively.

Debugging in Visual Studio Code

Visual Studio has been known for its excellent debugging tools. Some of the debugging tools you’ll find in VS Code.

In this blog, I’ll demonstrate how the debugging tools work with a simple JavaScript-powered web app. Yes, you could use the Chrome DevTools and do your debugging in the web browser. But VS Code allows you to debug right in the editor where you can make your fixes. It’s seamless! It also turns VS Code into a solid platform for teens and absolute beginners who are learning to code fo the first time.

VS Code debugging tools are fairly consistent, but if you want to debug JavaScript, you need to first install ‘the chrome debugger‘ and configure your project. Read on to know how to install.

  1. Start VS Code.
  2. Choose File→Preferences →Extensions from the VS Code menu (or just press Ctrl+Shift+X to get there in a hurry). This opens the EXTENSIONS panel on the left side of the VS Code window.
  3. In the search box, type “Chrome.” You’ll see the “Debugger for Chrome” extension appear at or near the top. Click the tiny green Install button next to that extension.

4.  Now close VS Code. The next time you run it, everything will be up to date.

Adding a debug configuration

If you try to start debugging your web page right now, it won’t work. The problem is that VS code assumes you’re hosting your site with a web server, and it expects to find that web server running on your computer. You could set this up with another VS Code extension and some more configuration.

Instead, what you really need is a new debug configuration – basically, some setup instructions that tell VS Code how to run your site. In this case, you want the debug configuration to tell VS Code to open your pages directly from the file system, rather than contact a web server.

Here’s how to add the debug configuration you need:

  1. Choose Debug Open Configurations.
Select Open configurations

2. Because you’re doing this for the first time, VS Code needs to know what sort of debugger you want. Choose “Chrome” from the list of options. (Don’t be worried if a warning message pops up in the bottom-right corner of the VS Code window, telling you that you don’t have the debugger for .NET Core. You definitely don’t need that.)

The Chrome debugger is the one you want

3. Now VS Code creates a configuration file named “launch.json“, and opens it in the editor window.

At first, the launch.json file looks something like this:

You need to modify these details to get the debugger to work properly. But don’t touch the type or request settings. They’re already good to go.

The name setting doesn’t have any effect, but it’s best to reword it to something that describes what you’re actually going to do (Like “Launch Chrome from the file system” or just “Launch Chrome”).

The url and webRoot settings tell VS Code to use a web server on your computer, which isn’t what you want. Delete these settings, and add a file setting that looks like this:

The ${workspaceFolder} part is a handy stand-in your current website folder. By using this shortcut, you ensure your project will keep working even if you rename the website folder or move it somewhere else.

Now, save your work with a quick Ctrl+S. When you do, VS Code creates a folder named .vscode inside your website folder, and places the launch.json file in there. As long as you leave that folder in place, VS Code will keep using the debug configuration you just set, and you’ll never need to crack open the .json file again.

Now it’s time for the moment of truth! To run your website, choose Debug → Start Debugging (or press F5). VS Code will start Chrome and point it to your website folder. Chrome will then show you a list of all the files in your website folder, which looks something like this:

Files in the “Website Project” folder

To load a page, click it in the list.

You could alter the ${workspaceFolder} setting to point to a specific page, like ${workspaceFolder}/Calculator.html. If you do that, Chrome will go directly to the page you specify when you run your VS Code project. But the folder list approach is usually more convenient for testing.

Now here’s the real test: is the debugger working? The easiest way to tell is to set a breakpoint  in your code. When your code hits the breakpoint, the execution of your page will pause, and you’ll be able to peek at your variables, run simple commands, and execute one line of code at a time in the VS Code window.

To set a breakpoint, open a JavaScript file, find the line you want to use, and click in the left margin (to the left of the line numbers). A red circle will appear to mark your breakpoint.

Here’s an example that puts a breakpoint on the line of code that sets the isDrawing variable in the Calculator.html page:

Click in the margin to add a breakpoint

Now, run your page again. When VSCode hits the breakpoint, everything freezes in the browser. Switch back to the VS Code window, and you’ll find your code paused at the point you picked. Now you can dig deeper with VSCode debug tools, or just hit F5 to resume your code and carry on.

Note:

The debugging approach you just learned works on any JavaScript file. But if you have a block of JavaScript code inside an HTML file, you’re more limited. Ordinarily, Visual Studio won’t let you set any breakpoints in HTML files. It’s picky that way.

If you run into this problem, there’s a simple workaround:

  1. Choose File→Preferences→Settings.
  2. Type “breakpoints” into the search box.
  3. Switch on the “Allow setting breakpoints in any file” setting.

Now you can add a breakpoint to any JavaScript, whether it’s in a separate script file or right inside your web page HTML.

The Calculator

Here’s is the page that contains a couple of common JavaScript mistakes.

The page is supposed to take two numbers ( in two text boxes ), add them together, and show the result. Unfortunately, the math doesn’t make sense. Clearly, there’s a gap between what we expect it to do and what actually takes place.

Here’s the code that does the adding when you click the button:

If you have programming experience, then you can probably spot the mistakes pretty quickly. But we’re more interested in exposing the problem with the VS Code debugging tools. Once again, you’ll need the Chrome debugger, but that’s it – this project already has . json file that switches on local debugging.

Single-step execution

One of the greatest tools in any programming language is the ability to step through your code. This feature allows you to watch your program in action, one line of code at a time.

To use this feature, you need to pick a place where you want to pause your code. You do this by adding a breakpoint — basically, a flag that tells Visual Studio “stop right here.” In the calculator example, the code is simple enough that you’ll probably want to step through the entire function. In other situations, you might want to skip over irrelevant or time-consuming parts by putting your breakpoint later.

To set your breakpoint, click in the margin to the left of the code line numbers. For example, to set a breakpoint at the beginning of the addNumbers() function, click next to line 2, which looks like this:

var numberA = document.getElementById("numA").value;

Now you’ll see a red circle appear next to the line you’ve marked:

A breakpoint set on line 2

To remove a breakpoint, click the red circle.

Unlike some development environments, VS Code lets you put breakpoints anywhere, even on variable declarations, comments, and blank lines. However, you can’t put a breakpoint on the function declaration (so in this example, a breakpoint isn’t allowed on line 1).

Now run your program in debug mode (choose Debug→Start Debugging from the menu or just press F5). VS Code will launch Chrome and show your page.

Everything starts out normally in the calculator. But when you click the Add Numbers button, VS Code hits your breakpoint and pauses your code. Often (but not always), VS Code will shade the browser window and add a yellow message to indicate when your code has been interrupted by a breakpoint:

What the page looks like when you hit your breakpoint

Now it’s time to switch back to the VS Code editor.

While your program is paused, you can use the commands described in the following sections. All of these commands have useful shortcut keys. They’re also all in the debugging toolbar (just hover over the icons to find out what’s what).

Continue (F5)

This command resumes the program and continues to run it normally, without pausing unless it hits another breakpoint.

Step Over (F10)

The Step Over command takes a single step. It executes the currently highlighted line, and then pauses again. If you try it in the current example, VS Code executes line 2, grabbing the value from the first text box. It then pauses just before executing line 3, which is supposed to get the number from the second text box:

Now VS Code is paused on line 3

Now you can hit F10 to take another step, and so on, until you march through the entire function one line at a time.

The “over” in Step Over refers to how this command works with function calls. If you use Step Over to execute a line of code that calls a function, VS Code runs the entire function, and pauses at the line underneath.

Step Into (F11) ↓ 

The Step Into command works the same as Step Over, except when it hits a function. Then, Step Into goes into that function and pauses on the first line inside.

Here’s the trick, though — this only works if the function is part of your code. You can’t step into something like the getElementById() function, because that’s a built-in part of the browser’s web page model.

In fact, in this example there’s no difference between using Step Into and Step Out. But if you write a function that called another function, you could use Step Into to travel from one place to another in your code, without skipping any details.

Step Out (Shift + F11)

The Step Out command executes all the code in the current function, and then pauses at the next statement (if there is one). In other words, it allows you to step out of the current function in one large jump.

In the calculator example, Step Out is almost the same as calling Continue. Why? The addNumbers() function wasn’t called by another function. Instead, addNumbers() was called directly from the onclick event in the HTML markup.

If you use Step Out in this case, VS Code takes you to the HTML page markup to show you where the event handler is attached:

Stepping out to the button that started it all

After that, there’s nothing else to do, so you may as well press F5 to continue on normally.

Stop (Shift + F5)

The Stop command is self-explanatory. This stops debugging, closes the browser, and lets you make your edits in VS Code.

Spying on variables

Single-step execution is a great way to follow through complicated logic. For example, you can find out how many times your code goes around a loop or which path your code takes through a block of conditional logic. But if you want to find out what’s gone wrong in a buggy program, you need to also look at the your application’s state — in other words, what it’s holding in memory.

Debug mode makes this easy. When your code is paused, you can hover over any of your variables with the mouse cursor to see what it currently contains. For example, if you move the mouse over the numberA variable immediately after the breakpoint is hit, here’s what you’ll see:

Remember, the breakpoint stops execution just before the line runs. In this example, nothing has happened yet, so it’s no surprise that numberA is “undefined.”

Now press F10 (Step Over) to run a single line of code and take another peek at numberA. You’ll see a box with the value “10”:

It’s important to understand that when you peek into a variable, you always see its current state. It doesn’t matter where you are in the code. For example, there’s no difference if you hover over numberA in line 2 or line 5, either way VS Code shows you what it holds right now. Similarly, if you hover over the result variable in line 5, it will be empty, because that line of code hasn’t been executed yet.

Fixing the error in calculator

Variable peeking is the secret to unraveling the first problem in the calculator example. Press F10 to run one more line, and look at the numberB variable. You’ll see that it has the same value as numberA.

Clearly, line 3 has a problem — it grabs the information from the wrong text box. Fortunately, the fix is easy. You simply need to correct the name that’s used to find the text box, by replacing numA with numB:

var numberB = document.getElementById("numB").value;

Once you’ve made this fix, you need to stop the program (Shift+F5), and start debugging again (F5). (VS Code will save the changed code for you automatically when you restart.)

If you keep stepping along, you’ll run into the second problem. The result of adding the two numbers (in this example, 10 and 15), gives you the long bit of text 1015 instead of proper answer 25. You can quickly home in on the problem using variable peeking after VS Code performs the calculation:

numberA value
numberB value
result value “1015”

(Keen eyes will notice that VS Code also shows you the value of all your local variables in the VARIABLES panel on the left side of the window, so you can see them at a glance.)

Thanks to debugging, you’ve been able to find where things go wrong. The problem is that this code is working with bits of text (like “10”) instead of numbers (like 10). When you use the plus sign on bits of text, JavaScript simply joins them together. To solve this problem, you need to translate both pieces of text into numbers, and then add those values.

There are several ways to convert text to numbers in JavaScript, with subtle differences in how they deal with bad data (text that doesn’t really have numbers in it). But here’s one example of how you might make a quick fix for this example using JavaScript’s Number() function:

var result = Number(numberA) + Number(numberB);
We got our perfect addition which is 25

Of course, in this example the fix isn’t what’s important. The real benefit is developing your debugging skills.

VS Code has several more advanced debugging tools. For example, you can create watches that track the values of certain variables, examine the call stack to figure out where you are in deeply layered code, and create conditional breakpoints that only trigger when certain conditions are met.

But single-step execution and variable peeking are the two core debugging tools that make everything else possible. With them, you never need to give up altogether when you face mysterious problem.

Hope this helps!

Thank You & Keep Learning.. 😊

Happy Coding & Peace.

About the author

iamsparkler

Add comment

Leave a Reply

By iamsparkler

Most common tags

%d bloggers like this: