New version page

REED MATH 121 - Debugging

Upgrade to remove ads
Upgrade to remove ads
Unformatted text preview:

Math 121: Introduction to Computing Handout #14 Debugging As soon as we started programming, we found to our surprise that it wasn’t as easy to get programs right as we had thought. We had to discover debugging. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. — Maurice Wilkes, 1949 The purpose of this lecture is twofold: to give you a sense of the philosophy of debugging and to teach you how to use some of the practical tools that make debugging easier. The philosophy of debugging With method and logic one can accomplish anything. — Agatha Christie, Poirot Investigates, 1924 Debugging is one of the most creative and intellectually challenging aspects of programming. It can also be one of the most frustrating. To a large extent, the problems that people face debugging programs are not so much technical as they are psychological. To become a successful debugger, onen has to think in a different way. There is no cookbook approach to debugging, although Nick Parlante’s rules in Figure 1 should help. What it takes is insight, creativity, logic, and determination. Figure 1. The Eleven Truths of Debugging 1. Intuition and hunches are great—you just have to test them out. When a hunch and a fact collide, the fact wins. 2. Don’t look for complex explanations. Even the simplest omission or typo can lead to very weird behavior. Everyone is capable producing extremely simple and obvious errors from time to time. Look at code critically—don’t just sweep your eye over that series of simple statements assuming that they are too simple to be wrong. 3. The clue to what is wrong in your code is in the values of your variables and the flow of control. Try to see what the facts are pointing to. The computer is not trying to mislead you. Work from the facts. 4. Be systematic. Be persistent. Don’t panic. The bug is not moving around in your code, trying to trick or evade you. It is just sitting in one place, doing the wrong thing in the same way every time. 5. If you code was working a minute ago, but now it doesn’t—what was the last thing you changed? This incredibly reliable rule of thumb is the reason your section leader told you to test your code as you go rather than all at once. 6. Do not change your code haphazardly trying to track down a bug. This is sort of like a scientist who changes more than one variable at a time. It makes the observed behavior much more difficult to interpret, and you tend to introduce new bugs.– 2 – 7. If you find some wrong code which does not seem to be related to the bug you were tracking, fix the wrong code anyway. Many times the wrong code was related to or obscured the bug in a way you had not imagined. 8. You should be able to explain in Sherlock Holmes style the series of facts, tests, and deductions which led you to find a bug. Alternately, if you have a bug but can’t pinpoint it, then you should be able to give an argument to a critical third party detailing why each one of your procedures cannot contain the bug. One of these arguments will contain a flaw since one of your procedures does in fact contain a bug. Trying to construct the arguments may help you to see the flaw. 9. Be critical of your beliefs about your code. It’s almost impossible to see a bug in a procedure when your instinct is that the procedure is innocent. In that case, only when the facts have proven without question that the procedure is the source of the problem will you be able to see the bug. 10. You need to be systematic, but there is still an enormous amount of room for beliefs, hunches, guesses, etc. Use your intuition about where the bug probably is to direct the order that you check things in your systematic search. Check the procedures you suspect the most first. Good instincts will come with experience. 11. Debugging depends on an objective and reasoned approach. It depends on overall perspective and understanding of the workings of your code. Debugging code is more mentally demanding than writing code. The longer you try to track down a bug without success, the less perspective you tend to have. Realize when you have lost the perspective on your code to debug. Take a break. Get some sleep. You cannot debug when you are not seeing things clearly. Many times a programmer can spend hours late at night hunting for a bug only to finally give up at 4:00A.M. The next day, they find the bug in 10 minutes. What allowed them to find the bug the next day so quickly? Maybe they just needed some sleep and time for perspective. Or maybe their subconscious figured it out while they were asleep. In any case, the “go do something else for a while, come back, and find the bug immediately” scenario happens too often to be an accident. — Nick Parlante, Stanford University The programming process leads the programmer through a series of tasks and roles: Design — Architect Coding — Engineer Testing — Vandal Debugging — Detective These roles require distinct strategies and goals, and it is often difficult to shift perspective from one to another. Beyond understanding the multiplicity of roles, the main point is that although debugging is extremely difficult, it can be done. It may take skill and creativity, but one can succeed by being methodical and persistent. Eric Roberts recommends Robert Pirsig’s novel Zen and the Art of Motorcycle Maintenance: An Inquiry into Values (Bantam, 1974) as the best exposition of the art and psychology of debugging.– 3 – Using an online debugger There is nothing like first-hand evidence. — Sir Arthur Conan Doyle, A Study in Scarlet, 1888 The key to debugging is to get the computer to show you what it’s doing. The computer, after all, is there in front of you. You can watch it work. You can’t ask the computer why it isn’t working, but you can have it show you its work as it goes. Modern programming environments like Eclipse come equipped with a debugger, a special facility for monitoring a program as it runs. By using the Eclipse debugger, for example, you can step through the operation of your program and watch it work. Using the debugger

View Full Document
Download Debugging
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...

Join to view Debugging and access 3M+ class-specific study document.

We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Debugging 2 2 and access 3M+ class-specific study document.


By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?