After reading all of the comments on the use of a debugger (that took quite a while considering all of the replies and reference articles), I feel I fall into a middle ground. If you're developing a whole software package that requires a lot (200+ lines of code) functions, subs, etc, you should be breaking your code down into more managable chunks. This, in most cases, kills the need for a debugger. If you are testing an idea (maybe to find out how stuff is going on behind that magic curtain), you can use Devel::Peek to get at some of the more obscure inards of Perl. If it's not that serious, you can use a bunch of $verbose and $debug variables combined with print statements to do the job. Of course, there can be times when you HAVE to use a debugger. During these times, you should not be afraid to use one. Debuggers were built for a purpose, we might as well put them to good use.

Using a debugger does not give you an excuse to write sloppy code. Remember, there will usually be others that will take on your code when you decide to leave. Writing readable code may make it easier for your competition to figure out your code. However, you need to step beyond that little "problem" and look at the bigger picture. I remember I was on the chatterbox last night (erm, morning...) and someone came on the box and asked if there was a way to obsfucate Javascript code using a Perl script. If you don't want someone handing you a garbled piece of junk to maintain, why would you want to hand garbled source code to others.

In short, practice good coding habits, and in general, you won't needa debugger. If things get kind of hairy, go ahead and use the debugger. After debugging, see if there is a way to slice the tasks in your code up into smaller chunks. One of the things I took from my Visual Basic class (besides hating VB ever since) was: "The smaller the subroutine, the less that can go wrong." If you can break one subroutine into 20 smaller subroutines, it will make things easier to track. Of course, your boss might not like you taking a little extra care with your code. Of course, in the same light, your boss will be very angry when you've spent 10 hours extra debugging one subroutine, when it could have been broken down into smaller subs.

"Write good code and the gods of the programming will be happy. Write bad code and the debugger might even send you to hell."

Theodore Charles III
Network Administrator
Los Angeles Senior High
4650 W. Olympic Blvd.
Los Angeles, CA 90019
323-937-3210 ext. 224
email->secon_kun@hotmail.com

In reply to Re: Perl debugging - a look at 'beta' mechanism by Necos
in thread Perl debugging - a look at 'beta' mechanism by vladb

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.