How to fix your code in 5 minutes – Part 2

How to fix your code in 5 minutes – Part 2

I hope you read the How to fix your code in 5 minutes – Part 1. If not then please do read that first. Now let’s see how to fix the bug hiding in your code.

Progamming meme

Understand the problem before you fix it “The Devil’s Guide to Debugging” is right: the best way to make your life difficult and corrode the quality of your program is to fix problems without really understanding them. Before you fix a problem, make sure you understand it to the core.

 

Confirm the defect diagnosis Before you rush to fix a defect, make sure that you’ve diagnosed the problem correctly. Take the time to run test cases that prove your hypothesis.

 

Relax Hurrying to solve a problem is one of the most time-ineffective things you can do. It leads to rushed judgments, incomplete defect diagnosis, and incomplete corrections. Relax long enough to make sure your solution is right. Don’t be tempted to take shortcuts.

 

Save the original source code Before you begin fixing the defect, be sure to archive a version of the code that you can return to later. It’s easy to forget which change in a group of changes is the significant one. If you have the original source code, at least you can compare the old and the new files and see where the changes are.

 

Change the code only for good reason Related to fixing symptoms is the technique of changing code at random until it seems to work. The typical line of reasoning goes like this: “This loop seems to contain a defect. It’s probably an off-by-one error, so I’ll just put a -1 here and try it. OK. That didn’t work, so I’ll just put a +1 in instead. OK. That seems to work. I’ll say it’s fixed.”

 

Before you make a change, be confident that it will work. Being wrong about a change should leave you astonished. It should cause self-doubt, personal reevaluation, and deep soul-searching. It should happen rarely.

 

Make one change at a time Changes are tricky enough when they’re done one at a time. When done two at a time, they can introduce subtle errors. Keep it simple: make just one change at a time.

 

Check your fix Check the program yourself, have someone else check it for you. Rerun the whole program to check for the side effects of your changes.

 

Add a unit test that exposes the defect When you encounter an error that wasn’t exposed by your test suite, add a test case to expose the error so that it won’t be reintroduced later.

 

Look for similar defects When you find one defect, look for others that are similar. Defects tend to occur in groups. If you can’t figure out how to look for similar defects, that’s a sign

that you don’t yet completely understand the problem.

This is taken from the book “CODE COMPLETE” written by Steve McConnell. Every Software Engineer Should read this book at least once. It contains lots of guides with real-time usage which can make you a better programmer.

YOU CAN BUY  THE BOOK USING THE BELOW LINK

Sree Hari Sanjeev

The founder and CEO of Wisdom Overflow. His enthusiasm and effort has taken the blog to next level. You will be motivated just by taking a look at his daily schedule.