When I wrote C for a living, I followed these steps to make sure that there was very little room for misunderstanding between what I thought I'd told the code to do and what it was actually doing.

• I compiled my code with maximum warnings on;
• I linted the code and cleaned up all of the warnings;
• I ran the code in the debugger and watched it do everything, while I tried to feed it circumstances that would exercise all of the code paths; and
• I went back and editted the comments in the source code so that they were up to date and as clear as I could make them.

After that, I was pretty sure the code would behave the way I expected it.

This week I'm upgrading an install script that I wrote some time ago. It's not great code, but it's fairly decent. As usual, I want to add the new code so that I don't have to come back and hack it at 4am when things are broken. So I write the code, look at it, poke it, prod it, run it, fix it, then run it from the debugger, checking things as I go. As soon as something happens in the debugger that diverges from my understanding of what *should* have happened, I investigate and fix the problem, or realign my understanding of the solution.

As before, once the debugger tells me the code is working the way I thought it was, then my work is substantially done. You can do it using Data:Dumper too -- I use that along with Logger::Log4Perl sometimes -- but developing with a debugger is something that I'll always do.