Home

Syllabus

Notes

Homework

Grades

---

Debugging -- Coding for debugability

---

Debugging -- Coding for debugability
The joy(?) of debugging
What's coding style got to do with debugging?
Variable and function names
Make it clear what your code is doing

---

Reading: The Practice of Programming, Chapter 1, Style

The joy(?) of debugging

• What you do in school is completely different than the "real world"

• One-time programs that are never used again are not realistic.

• Real programs have lifetimes.

• Often long ones.
• Y2K problems were just one example of the sort of problems when old code needs to be fixed or updated.

• A bug is discovered in a 3-year-old program....

• Maybe you wrote it; maybe you didn't
• It's your job to find the problem and fix it.

• What are you going to do?

What's coding style got to do with debugging?

• The first step in debugging is to write clear, easy-to-read code.

• This will make any future debugging much easier.
• This will often prevent some debugging, by reducing errors in your code.

• Example from p.1 of the book:

 
if ( (country == SING) || (country == BRNI) ||
 (country == POL) || (country == ITALY) )
{
 /*
 * If the country is Singapore, Brunei or Poland
 * then the current time is the answer time
 * rather than the off hook time.
 * Reset answer time and set day of week.
 */

• This follows all of the "rules"

• The code is readable
• The comment block explains what's going on

• But it's very hard to maintain

• Why those four countries?

• What's special about them?

• Why doesn't the comment match the code?

• Where did Italy come from?

• Under what circumstances would I add another country?

• There is nothing about this code to help me debug of maintain it.

Variable and function names

• Variable names should be clear, but not needlessly long
• The book's rather extreme example

 
for (theElementIndex = 0; theElementIndex < numberOfElements;
 theElementIndex++)
 elementArray[theElementIndex] = theElementIndex;

• Compare that with:

 
for (i =0; i < nelems; i++)
 elem[i] = i;

• Likewise, functions should be given simple names that accurately describe what they do, and be a verb

• One example, isoctal() is a better name than checkoctal()

• Check it for what?

• In general, if what you're doing is straightforward, then code in a simple manner, and avoid overblown comments and complicated variable names.

Make it clear what your code is doing

• Indent to show structure

• But get it right!

• Write expressions like you would say them

• if (!a > b) isn't as clear as if (a <= b)

• Use parentheses, even if you don't really need them
• Break up complex expressions
• Be clear
• Code consistently
• Code in the idioms of the language you're using
• Use if, else-if structures to show parallel decisions in code
• Give names to magic numbers
• Don't comment the obvious
• Don't contradict the code in comments
• Write comments that clarify what the code is doing, rather than just restate it.
• The book has many other tips, and several examples. Read and heed.

---