1. consider one defect at time
  2. define the problem. Making an intermittent defect occur predictably is one of the most challenging tasks in debugging.
  3. Locate the source of the error
    1. Gather the data that produces the defect
    2. Analyze the data that has been gathered, and form a hypothesis about the defect
    3. Determine how to prove or disprove the hypothesis, either by testing the program or by examining the code
    4. Prove or disprove the hypothesis by using the procedure identified
  4. Fix the defect
  5. Test the fix
    1. Look for similar errors

Finite Steps to Debugging

Debugging is a science. You collect data, make a hypothesis based on your previous experiments and data, then make predictions (and experiments) either for or against the hypothesis. Next you run the program, providing it with new and hypothetical input; then you observe its output and then either confirm or refute your original hypothesis. What follows is a short list of steps to follow to solve the bugs you invariably create in the process of program writing.

Note

The real first step is to not write buggy code in the first place. This may seem like a no-brainer, but is important to consider. When a good chess player plays a game he is constantly thinking at least five moves ahead. With 16 different pieces, that could be more than a million different moves. Of course, the chess player doesn't need to analyze every possible move because he knows that many of them would be bad. Experienced players no longer seem to even see the possible bad moves. The same principal applies to program writing. As you become more experienced, you will make fewer and fewer mistakes that result in bugs. Eventually, you will no longer even think about the common mistakes that beginning programmers make—it will become second nature to write non-buggy code.

The first thing to do when you do encounter a bug is to find out as much as you can about it. Read the error message carefully; it will usually tell you exactly what the problem is. If you don't understand the error message, your second best resource is the Internet. Unlike in grade school, looking up an answer is not cheating in the computer industry.

After finding out as much as you can about the error, the next logical step is to fix it in your source code. If it is a simple bug, by all means dive right in.

The last step in debugging is to test your changes. If everything works correctly, then great, you're done. If not, jump back up to step one and start again. You can't fix a program unless you understand how it works or should work in the first place. Tools will help you collect data, but it can't interpret it for you, and it certainly can't fix the problem.

Riassumendo

  • raccogli tutti i dati possibili
  • fai tutte le ipotesi possibili, trova il risultato atteso
  • crea esperimenti che confutino alcune ipotesi in modo da escludere alcune cause o capire il meccanismo

Notice: Undefined variable: browserName in /var/www/taziomirandola.it/lib/Visitors.php on line 86

Notice: Undefined variable: browserName in /var/www/taziomirandola.it/lib/Visitors.php on line 96

Deprecated: strripos(): Non-string needles will be interpreted as strings in the future. Use an explicit chr() call to preserve the current behavior in /var/www/taziomirandola.it/lib/Visitors.php on line 96

Notice: Undefined index: HTTP_ACCEPT_LANGUAGE in /var/www/taziomirandola.it/lib/Visitors.php on line 39

Fatal error: Uncaught TypeError: Argument 1 passed to safe_text() must be of the type string, null given, called in /var/www/taziomirandola.it/lib/Visitors.php on line 39 and defined in /var/www/taziomirandola.it/lib/Visitors.php:162 Stack trace: #0 /var/www/taziomirandola.it/lib/Visitors.php(39): safe_text() #1 /var/www/taziomirandola.it/lib/Visitors.php(124): Visitors::getData() #2 [internal function]: Visitors::log() #3 {main} thrown in /var/www/taziomirandola.it/lib/Visitors.php on line 162