Debugging

 

Debugging

L0ftFC          May 6^th 2009

Thanks to Mehran Sahami and Nick Parlante for portions of this article.

(writer said:I am a freshman of Software Engineering major.This is the first time I write an issue totally in English.So I appreciate your any correction.THANK YOU! )

            Programming is almost the happiest thing in my life. But the more code I write, the more faults I will make. Also some faults are easily corrected. But others are not, especially the program being more complex. So debugging plays

an important role in the future programming.

         Bring in the quotation which Maurice Wilkes said:

        

As soon as we started programming, we found to our surprise that it was easy to get problems right as we 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

 

Even now we may not understand clearly how important debugging is(just to freshman like me). Debugging is everywhere. So knowing the philosophy of debugging and some practical tips that make testing and debugging easier will be good in undertaking the more complex future debugging that many of us will dong.

         Debugging is not just several rules. Actually, no rules’ debugging may be the best debugging. So what debugging really needs. As the commercial of apple said: Think different, debugging needs the point——think different. Insight, creativity, logic and…whatever you have thought. I have also heard about Google’s help, but it may not get what you want……

         I have ever listened to a excellent course of programming methodology in Stanford university (cs106). In this class, their teacher had listed a series of tasks and roles in programming process:

                           Task    ------    Role

                            Design   ------   Architect

                            Coding   ------   Engineer

                            Testing   ------   Vandal

                            Debugging   ------   Detective

Four-step needs so many rounds to do until the problem is really solved.

         Exactly testing needs vandal. I like a comparison: program likes a river, bugs are factories which pour waste water into the river. And what debuggers should do is to clean it. Firstly you should find the accurate point where the bug is. So don’t be so mercy! You need to try to “break into” your program, just like what vandal always do.

         However sometimes you have found the bug, you also don’t know what causes it and how to correct it. Now the long and hard journey just begins. You must plan ahead and allow sufficient time for debugging and testing. These are The 11 Truths of Debugging (which is written by Nick Parlante, Stanford University) which I have summarized for short and simple. Maybe it will help the freshmen just like me. But if you are professional, please don’t be involved in the fixed thoughts. Try to develop your skill in debugging and you will benefit it a lot. Again, debugging is creativity.

Tips:

1. Trust yourself:

 Intuition and hunch are great. Test your hunch and follow the fact.

2. Simple maybe wrong:

Simplest may be the worst. No matter who you are, simplest problem will also trouble you——don’t just sweep your eye over that simple lines of code that they are too simple to be wrong. Be critical to yourself.

3. Panic = fatal:

Don’t panic. Be systematic and persistent. Bug can not go about in your program. Every time he dose is the same thing in the same place. Find the naughty boy.

4. Watch out your values:

a. Following the values in your code is always a useful way to find out who make my program lost.

b. When you follow your values and change one to see what will happen, try to fix others. The more values you change, the harder you can find the bugs.

c. To functions, what values you pass to them and what they return are the key to find problem. Especially watch out different styles of values between what the original declaration of function needs and what you pass to the function to run.

5. Logic:

        Ask yourself: what has my code done. Run your code’s logical process not only in your machine, but also in your mind. Find out the code-block which causes my program wrong. 

        Unit test: When your first step is successful, or just your hunch tells you “bug here”, you just need to test one function or one unit. This time you can use the compiler’s tools, or make a driven program to test it on purpose or whatever. All is up to you.

        Of course debugging is more than what I had point here. And what I discussed is just the traditional programming’s debugging. But there is not any more changes then one point——Think Different.