Use these methods to save your time while you are playing with software bugs.

Shalitha Suranga

Follow

Jan 23 · 3 min read

Wherever a software system exists, bugs also exist. A particular feature can have many different cases and workflows. Programmers might miss a few edge cases in their implementations. Missing conditions, edge cases, and typos may create bugs in software systems. All most all bugs cannot be prevented during the feature implementations phase. Therefore, we will have to apply fixes when a user or a tester finds a specific bug in our software products. Sometimes, debugging takes more time than implementing a new feature. Hence, it is so important to find out ways to boost your productivity while you are debugging.

I use the following tips and tricks to spot bugs easily while playing with JavaScript-related bugs.

The debugger keyword

Perhaps, you will start to debug a particular buggy piece of code by opening the developer tools. After that, you will find the source file and will begin adding breakpoints. If you have a lot of source files, it will take a long time to find out where you need to add breakpoints.

If you include debugger keyword, developer tools will automatically set a breakpoint for the particular location. Then you will be able to put the rest of the breakpoints to kill the bug. Don’t worry if you forget to remove debugger in the production code. It won’t break anything for users unless someone activates the developer tools feature in the web browser.

Debugging on real mobile devices

Testing and debugging of mobile web apps is possible by creating mobile simulators or emulators. But if your web app is having actions for swipes and touch events like mobile hardware-related things, it is better to debug and test on real mobile devices. If a particular feature is working fine on your physical test devices, we can guarantee that it will work on other physical devices.

I usually don’t use either simulators or emulators for debugging mobile apps or mobile web apps. Because I don’t trust simulators and emulators will slow down my computer. I found the following article for setting up remote debugging with the Chrome browser.

Analyze your code before putting any breakpoint

There are three kinds of people when it comes to debugging JavaScript:

• Debuggers: Developers who jump to the developer tools to set some breakpoints before doing anything.
• Anti-debuggers: Perhaps, they don’t know about breakpoints. Otherwise, they are afraid to touch the developer tools further. These developers always useconsole.log until they find out the root cause for the bug.
• Bug-killers: They will look at the code. If it is simple to verify by the mind. they will use console.log. Otherwise, they will set up breakpoints to the right place.

Try to become the third type. First of all, we can analyze code to find out the failing point. If it is clear and understandable, there is no need to waste your time on the developer tools. On the other hand, if it is unclear and it is occurring sporadically the wise choice is to go ahead with developer tools by using the results from the code analysis rather than taking too much time to fix it just by looking at the code.