I don't really want to spend time thinking "If this code has a bug, what's the best way of writing it so it's easy to spot?"

One the one hand, I'd say "well then don't spend time thinking about that", but OTOH, I don't actually see anything wrong with thinking that way. If the debugger is a tool you use regularly, there's no avoiding the fact that you will become familiar with its limitations, and a natural outcome will be to adjust the coding style to avoid them. To wit:

I realize there are several things there that could be changed to improve the error reporting. For instance, since most of the blocks return, the elsifs could be ifs instead.

If you went ahead and did that, would your code be worse in any way than it is now? Not really. In fact, this particular example would seem nice if it were phrased like this: 

  for my $i ( 0..(@a < @b ? $#a : $#b) ) {
    return $a[$i] <=> $b[$i]
        if ( $a[$i] =~ $NUMBER_ONLY_REGEX and 
             $b[$i] =~ $NUMBER_ONLY_REGEX and
             $a[$i] != $b[$i] );
    return $a[$i] cmp $b[$i]
        if ( $a[$i] ne $b[$i] );
  }
  return $a cmp $b;

[download]
I do agree that the issues with compiler error reporting, as discussed in your other thread, can be a problem. If I felt like I had to develop a coding style specifically to overcome this limitation, I might try something like this: 
if ( condition1() ) {
    do_first_thing();     goto ENDIF_1;
}
if ( $undeclared_scalar = condition2() ) {
    do_second_thing();
    do_something_else();  goto ENDIF_1;
}
{
    do_default_thing();
    $other_default_work = even_with_typos;
}
ENDIF_1:  # and now back to our regular programming...

[download]
That makes it easy/possible for "perl -c" to report meaningful line numbers for typos, and allows me to pause the debugger at each condition. Once I'm past that stage and it's working okay, I could go over it one last time and easily change it to "if ... elsif ... else", remove or comment out the "goto" statements and the "ENDIF_1" label, and everything's back to normal. Even the line numbering stays the same.

(I doubt that I would do this globally or by habit, but I could easily imagine using it as a fallback strategy on an as-needed basis, just to get some honest ground truth from the compiler and debugger when I'm not able to spot the bug easily on my own.)

In reply to Re: No Pause on Elsif in Debugger, Part 2 by graff
in thread No Pause on Elsif in Debugger, Part 2 by QM

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.