in reply to RFC: Basic debugging checklist

If you use good IDE then 2, 4 and 5 become either redundant or trivial without making any code changes.

Running your code through PerlTidy can show up issues hidden by slack indentation or incorrectly paired tokens (quotes, brackets, ...).

It often helps to comment out chunks of code or put temporary early exits into subs so you can focus on the problem area. That technique can be counter productive if you forget to restore the code though!

Use a revision control system so that you can back out of large changes easily that may have been made while tracking a problem down.

True laziness is hard work

Replies are listed 'Best First'.
Re^2: RFC: Basic debugging checklist
by JavaFan (Canon) on Feb 18, 2009 at 23:57 UTC
    Running your code through PerlTidy can show up issues hidden by slack indentation or incorrectly paired tokens (quotes, brackets, ...).
    But that's redundant or trivial when using a good IDE (which doesn't have to be more advanced that a modern vi clone).
[reply]
Re^2: RFC: Basic debugging checklist
by toolic (Bishop) on Feb 19, 2009 at 18:27 UTC
    It often helps to comment out chunks of code or put temporary early exits into subs so you can focus on the problem area.
    Excellent point. I seem to remember a node dedicated to this topic here at the Monastery, but I do not have it bookmarked, and my search-fu is weak. I also seem to remember that you were the author. I will continue looking because I think it would be useful to link to it here.
[reply]

      You may be remembering:

      Start with the code that shows the problem and consider the minimum input and output requirements to demonstrate the problem. Then reduce the code and data as much as possible while still showing the problem.

      from I know what I mean. Why don't you?.

      True laziness is hard work
[reply]
        Yes, I believe that's the node.
[reply]

In Section Meditations