Debugging your code

Debugging is essential. More accurately, debugging is inevitable. Extending from the previous post on testing, a perfect project is a rare occurrence.

Given the inevitability of debugging, it is worth mentioning that this demonstrates the need to write clear and concise code, and comments. When working in a team greater than just yourself, there is a good possibility that you will not just be debugging your own work.

The process of debugging takes place over three stages: reproducing the bug, isolating the cause, and finally resolving it. Technically there is a stage zero: identifying and reporting the bug, which we shall consider next.

Reporting bugs

Bug reports can take many forms, but will share the following indispensable items as according to Maker.io:

  • ID/name: Keep it brief and use correct terms. A best practice is to include the name of the feature where you found an issue. A good example could be ‘CART – Unable to add new item to my cart’.
  • Description/summary: If you feel the name is not enough, explain the bug in a few words. Share it in easy-to-understand language. Keep in mind that your description might be used to search in your bug tracking application, so make sure to use the right words.
  • Environment: Depending on your browser, operating system, zoom level and screen size, websites may behave differently from one environment to another. Make sure your developers know your technical environment.
  • Source URL: Make it easy for your developers spot the problem by including the URL of the page where you found the bug. Big time saver!
  • Visual proof: A picture is worth a thousand words. Although it might not be enough, a visual element like a screenshot or a video will help your developers understand the problem better and faster.
  • Steps to reproduce: A screenshot is a proof that you had a problem, but keep in mind that your developer might not be able to reproduce the bug. Make sure to describe, with as much detail as possible, the steps you took before you encountered the bug.
  • Expected vs. actual results: Explain what results you expected – be as specific as possible. Just saying “the app doesn’t work as expected” is not useful. It’s also helpful to describe what you experienced.
  • Optional: You can also include extra information such as the severity (critical, major, minor, trivial, enhancement), priority (high, medium, low), name of the reporter, person assigned or a due date.

Types of bugs

Bugs are myriad, but as a rule they take one of three forms:

  • Syntax: Something wrong with how you have written your code, such as this missing parenthesis
<script type = "text/javascript">
      console.log("Hello World!";
</script>
  • Runtime: When the code runs but may contain an error that you don’t know exists, for example something that causes a script termination, like an undefined method/function
<script type = "text/javascript">
      window.printme();
</script>
  • Logic: Something doesn’t logically work how it’s intended such as an incorrect calculation
<script type = "text/javascript">      
      let a = 1;
      let b = "2";
      let sum = a + b;
      console.log(sum)
</script>

Resolving bugs

You will encounter bugs both during development, but also from production. Starting first with while in development, your code editor and local build environment can offer you feedback.

Within VS code, you will get warnings about errors you may have made in your code:

screenshot of a vs code error

Additionally, and this can apply to both local and production, is the might and power of Google Chrome Dev Tools. With the Dev Tools, you not only get a console in the browser which will show you any console exceptions, but can also delve further into the content for more information.

Debugging in action

To further demonstrate the functionality of the Chrome Dev Tools, I’m working through a tutorial which helps to highlight some of them:

Leave a Reply

Your email address will not be published. Required fields are marked *