Quantcast
Channel: Debugging – The Wiert Corner – irregular stream of stuff
Viewing all articles
Browse latest Browse all 40

How to debug small programs

$
0
0

As a follow up of SSCCE, MWE and MCVE are basically the same: provide code people can use to reproduce a problem, I found [WayBackHow to debug small programs which is starts as

One of the most frequent categories of bad questions I see on StackOverflow is: I wrote this program for my assignment and it doesn’t work. [20 lines of code]. And… that’s it.

Then it goes on how to debug those pieces of code, trim them into an SSCCE/MWE/MCVW to form the base of a question which you can ask on StackOverflow/SuperUser/ServerFault/StackExchange, forum, group/community or even your co-worker.

The really cool thing about the techniques used there are that they also apply to bigger pieces of code, heck even large code bases.

They force you to trim down your problem in to manageable pieces that are easy to explain and write concise documentation and tests around them to assist you in the process.

Below are the steps in a short list. Be sure to read the original article How to debug small programs | Fabulous adventures in coding after going through the list.

  1. Turn on compiler warnings, inspect all of them, resolve or explain them
  2. Rubber duck to an imaginary person or even a live one explaining each part in simple terms
  3. If the bug is still there, break up the code into pieces
  4. Write technical specifications for all the pieces
  5. Verify the pieces against the specifications, for instance by adding pre- and postconditions to them
  6. Add assertions in the pieces for all the specifications
  7. Write test cases for the pieces
  8. Write down on paper the expected behaviour for all the lines of code
  9. Use a debugger to step through all the lines of code and verify the expected behaviour you wrote down
  10. While debugging, listen to all your doubts (gut feeling is a good thing!)

This sounds like a lot of work. It is. All good programming is.

If you apply these before writing any logic code, then your life becomes easier because you will spot bugs sooner:

  • specification
  • test cases
  • preconditions
  • postconditions
  • assertions

Does this again sound like a lot of work?

Then remember: taking a shortcut will make the actual work longer. The reason is that hunting for bugs is a tedious and time consuming process scaling very badly with complexity.

–jeroen


Viewing all articles
Browse latest Browse all 40

Trending Articles