This is when I request a senior developer for assistance. Finding a ton of
console.log in my code, the senior developer gave me a piece of advice that changed my JS development workflow. This story conveys the same advice.
To debug a piece of code, it is common practice to print variables and messages. A developer can understand the code flow and verify that variables are receiving expected values by using these messages. The presence or absence of these messages also indicates whether or not a specific region of the code is executed. This method of debugging is undeniably effective, and many developers use it to debug code in the early stages of their careers.
But as a developer continues to grow, it is common to face limitations in debugging the code via this method. Managing a large number of messages is one of the biggest challenges. The ability to view different parts of variable is often required while debugging a code.
Sometimes you may only need to see a field of an object to debug the code while the other time you may need to view the entire object. Making these changes in the debug messages requires us to re-run the program. A re-run of the program is sometimes inconvenient and often not possible.
Thus using messages to debug the code might solve the purpose but as our debugging need grows we need better and more potent ways of debugging our programs.
So seeing me struggle to debug a JS code running in a browser, the senior developer asked me if I know how to use Chrome Dev Tools. Completely unaware of Dev Tools until that point in time, the senior developer introduced me to debugging tools provided by Chrome Browser.
Chrome dev tools is a special UI in developer tools that makes debugging much easier. It also allows tracing the code step by step to see what exactly is going on.
There are a number of benefits that developer tools provide above the normal logging method of debugging. Some of these are -
The debugger for JS code in the Chrome browser can be found under developer tools. Press
F12 to open the developer tools. Once on the developer tools, select
Sources panel. Here is what you would see:
Consider it as if you are running your favorite IDE right inside your browser. You can go through your files and inspect them. The toggler button, on the top left, opens the tab with files.
Sources panel in Chrome dev tools.
Open the file panel by clicking on the toggler button. This will display the files in the workspace. Double click on the file
hello.js to open it in the file viewer. This is what you should be looking at -
The Sources panel is divided into three sections:
We can create breakpoints in the code right inside the code editor available in the sources panel. These can then be used to debug the code and trace code execution.
Let us now try creating some break points in the
hello.js file. Click on line 4, right where the number is written. You should see a blue bar appearing on the top of the line number. Try creating a breakpoint at line number 8. The editor should now look something like this.
Now refresh the webpage and notice the execution stopping at line number 4. Focus on the informational section of the debugger.
The informational section allows us to examine the current code state:
Watch – shows current values for any expressions.
You can click the plus
+ and input an expression. The debugger will show its value, automatically recalculating it in the process of execution.
Call Stack – shows the nested calls chain.
At the current moment, the debugger is inside
hello() call, called by a script in
index.html (no function there, so it’s called “anonymous”).
If you click on a stack item (e.g. “anonymous”), the debugger jumps to the corresponding code, and all its variables can be examined as well.
Scope – Shows the current variables.
Local shows local function variables. You can also see their values highlighted right over the source.
Global has global variables (out of any functions).
this keyword there that we didn’t study yet, but we’ll do that soon.
Let us continue the code execution by clicking on the resume button (blue colored play button). Clicking on this button instructs the debugger to continue execution until the next break point. In our case, you should see the code execution stopping at line 8.
We can use the call stack collapsable to see the execution trace. Verify that we are at line 8 of the
hello.js file inside the function
say(). The row below it shows that the call to the
say() the function is made from line 4 of
hello.js file inside
The execution of the code can also be controlled through various options available besides the resume button.
Here is a brief description of each of them (in order from left to right, starting from second option) -
The use of debuggers can make a developer’s life much easy. When compared to warriors, a developer who knows about debuggers is a soldier on horseback, but a developer who does not know about debuggers is like running on foot on the battlefield. If you are still not using debuggers, you should start doing them today since this will make your work far better.
In the end, do follow me on Twitter and stay connected for more articles like this. Hit the like button if you like what you are reading.