How to fix your code in 5 minutes- Part 1
Have you ever stuck in an error for endless hours and somehow fixed without knowing exactly what you did? Then this post is for you. Here is the list of the things to fix your code like a pro.
Keep a notepad by your desk, and make a list of things to try One reason programmers get stuck during debugging sessions is that they go too far down dead-end paths. Make a list of things to try, and if one approach isn’t working, move on to the next approach.
Talk to someone else about the problem
You often discover your own defect in the act of explaining it to another person.
Be suspicious of classes and routines that have had defects before Classes that have had defects before are likely to continue to have defects. A class that has been troublesome in the past are more likely to contain a new defect. Reexamine error-prone classes and routines.
Check code that’s changed recently If you have a new error that’s hard to diagnose, it’s usually related to code that’s changed recently. Check the version control log to see what code has changed recently. If that’s not possible, use a diff tool to compare changes
Use all the data available to make your hypothesis When creating a hypothesis about the source of a defect, account for as much of the data as you can in your hypothesis.
Exercise the code in your unit test suite Defects tend to be easier to find in small fragments of code than in large integrated programs. Use your unit tests to test the code in isolation.
Use available tools Numerous tools are available to support debugging sessions: interactive debuggers, picky compilers, memory checkers, syntax-directed editors, and so on. The right tool can make a difficult job easy.
Generate more data to generate more hypotheses Choose test cases that are different from the test cases you already know to be erroneous or correct. Run them to generate more data, and use the new data to add to your list of possible hypotheses.
Brainstorm for possible hypotheses Rather than limiting yourself to the first hypothesis you think of, try to come up with several. Don’t analyze them at first—just come up with as many as you can in a few minutes. Then look at each hypothesis and think about test cases that would prove or disprove it. This mental exercise is helpful in breaking the debugging logjam that results from concentrating too hard on a single line of reasoning.
Narrow the suspicious region of the code
If you’ve been testing the whole program or a whole class or routine, test a smaller part instead. Use a binary search
algorithm to focus your search. Try to remove about half the code the first time. Determine the half the defect is in, and then divide that section. Again, determine which half contains the defect, and again, chop that section in half. Continue until you find the defect.
Integrate incrementally Debugging is easy if you add pieces to a system one at a time. If you add a piece to a system and encounter a new error, remove the piece and test it separately.
Take a break from the problem
How many times have you paused for a cup of coffee and figured out the problem? If you’re debugging and making no progress, once you’ve tried all the options, let it rest. Go for a walk. Work on something else. Go home for the day. Let your subconscious mind tease a solution out of 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