in reply to Defensive Programming

Hmm. I would say that there are much better defensive programming moves that you can make with your snippet.

You posted 

for (@$Courses) {
        if ($Course = CheckCourse($_)) {
            print PageCourseInfo($Course);
            $count ++;
        }
        else {
            last;
        }
        last if $count >= 10;
}

[download]
Which I would probably not write in the same way at all. First you are using an assignment in a conditional. While this is not wrong personally I think its a bad call most times. Reason being that its easy to think that youve made the "=" instead of "==" typo. Second point would be that when writing an if/else block its usually a good idea to put the smaller block first, changing the condition as is necessary. Third instead of doing your >= you could have been even simpler and used <. Anyway, heres how I would have written the same thing 
for (@$Courses) {
        my $Course = CheckCourse($_);
        last unless $Course;

        print PageCourseInfo($Course);

        last unless ++$count < 10;
}

[download]

Yves / DeMerphq
--
When to use Prototypes?

Replies are listed 'Best First'.
Re: Re: Defensive Programming
by bmcatt (Friar) on Jan 14, 2002 at 21:02 UTC
    Rather than just saying "it's usually a good idea to put the smaller block first", I like to think of it as shortening the main-line logic. Whenever one side of an if-else winds up being a short-circuit exit (last, next, return, etc), I find it's much cleaner to just put that by itself to show that I'm figuring out how to do the short-circuit. Then, the else disappears and you've managed to reduce the indentation level by 1. In my book, that's always a Good Thing™.

    All of which is probably a fancy way of saying that the rewrite (above) looks good, I'm just disagreeing (maybe) on why it's better. :-)

[reply]
[d/l]
      Oh I agree completely. I actually originally put a line like "and in perl you have even better options with the modifiers that are available" but it didnt quite fit so I took it out. Perl modifiers and control flow keywords are an excellent way to minimize excessive indentation and containment problems.

      Nevertheless I do think that "the smaller part of a conditional should go first" is a correct rule of thumb. If you have a 4 line block and a 40 block then the 4 liner should go first. This means the maintainer can see all of one and part of the other on one page, whereas with the long block first the maintainer can only see part of one block, and may not even notice the presence of the smaller one.

      Yves / DeMerphq
      --
      When to use Prototypes?

[reply]
        The rule, "the smaller part of a conditional should go first" conflicts with the rule, "the expected path should go first". The justification for the second rule is that it makes the code more natural to skim. That is, of course, secondary to wanting to make it clear what is part of the conditional. But it is not totally irrelevant.

        I usually put the expected result first, and avoid the size issue by moving the body of long blocks into functions. That probably works 95% of the time. The exceptions are mainly cases where I have nested control logic that I want to keep in one place, or situations where I need to inline a long piece of text (eg an SQL statement). Then I will move the shortest block first for the reason that you give.

        So my rules in order of precedence are to make it obvious what belongs to the conditional, and then to make the most common flow of the program match the natural flow of skimming. But the more important can usually be satisfied without harming the second, and I do.

[reply]

In Section Meditations