Fixing Bugs and Refactoring Code

Lou Bison
5 min readMar 23, 2019

--

debugging

Bugs! Some fear them, others hate them, many get goosebumps at the sight of them, I crush them under my shoe. Really nobody likes bugs. It can be such an embarrassment if one popped out of your bag.

In software development, we have bugs as well. Of course, not your normal creeping six-or-so legged creatures, but they are as annoying and embarrassing.

A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.

Imagine you are presenting a long-anticipated feature, one you had talked up and assured your stakeholders will save the business some few hundred bucks. And just at the start of your presentation, a bug raises its ugly head. You were sure this feature worked the last time you ran it. You can’t fix it in the middle of the presentation, all you can do is apologize, make another appointment and promise to find the bug. The embarrassment!

Debugging
Finding bugs in software is the process known as debugging. Before you can vent your anger at a bug, you need to find it. In over a dozen files and over a thousand lines of code, how do you find one small, but annoying bug?

In almost all software development editors, there is a provision to run your software in debugging mode. What does this mean? It means you can pause code execution and step through your code sequentially, line by line.

I am not conversant with most code editors, so I will demonstrate debugging using Visual Studio Code.

Talk about appropriate icons. The feature with an icon of a bug canceled out can only be debugging.

Breakpoints
Breakpoints allow you to pause the program at a certain point when running in debugging mode.

Just where would you set a breakpoint? The technique is to place the breakpoint before the piece of code you suspect has the bug.

Notice the breakpoint on line 67

With the breakpoint set, simply run your program by pressing the play button in the debugging menu. Assuming the bug is after the breakpoint, the program will run and pause at the breakpoint you set. If the app crashes before hitting the breakpoint, move or set another breakpoint to a point before the current breakpoint. Keep doing this until a breakpoint is eventually hit.

Program paused at the breakpoint
Debugging control

With the debugging control, you can run your program step by step line by line, until you hit the piece of code causing the bug. Gotcha!

Notice on the side, under the variables submenu, you can examine the variables for their current value. This and many more features make the hunt for your bug fast, even enjoyable!

Kill the bug once and for all time.
Having gotten rid of that nagging bug, what assurance do I have that it won’t appear again during my presentation? Well, if you think you don’t have any assurance, — you absolutely right. Until you set measures to detect the bugs before your presentation, bugs might continue to pop up every now and then. One technique I use to kill bugs completely is TDD.

TDD
What is TDD? TDD is a software methodology where tests are written first before the functional code.

Testing various login input scenarios

To kill bugs once and for all time it is imperative that you write extensive tests for your application. After adding a new feature, you can run these tests. If any of these tests fail, you can easily find the faulting piece of code. Before presenting your software, first, make sure your tests are all passing. This gives you an assurance that your application is running as expected.

Refactoring code

Sometimes bugs manifest themselves in the form of inefficiencies in our application. A simple task may take way longer than reasonably expected. For example, if it takes a whole minute to log into your application, then rest assure you are not going to have a lot of traffic to your application.

An inefficient piece of code

Take an example of the piece of code above. If you examine it carefully, you'll realize that I am validating the username and email twice. This makes debugging and reading my code difficult, and if I have more of these duplications, my runtime might grow to a considerable and disturbing amount of time. Hence the need for refactoring.

Refactored and more efficient code

With the refactored code, my application runs faster, the code is more readable and finding bugs is much easier.

So before releasing a version of your application, scour through your application looking for ways to remove redundancies and code duplications, This will help keep your app lean, mean and super efficient.

Conclusion

While may dread and fear bugs, you should not be among them anymore. With the debugging techniques explained herein, finding a bug is just another opportunity to enjoy the satisfying popping sound as you squash it underfoot.

Happy debugging!

--

--