in reply to Re: Re: A matter of style
in thread A matter of style

Purists are theorists, not do-orists. I'm a do-orist. Let's say I have a N-tree of objects and some function that walks the tree and executes itself on each child of a given node. Now, I want to stop walking the tree if any child returns 0 instead of 1. 
# Impure
sub walk_and_do
{
    my $self = shift;

    foreach my $child (@{$self->children})
    {
        return 0 unless $child->walk_and_do;
    }

    return 0 unless $self->do_my_stuff;

    return 1;
}

#####

# Pure
sub walk_and_do
{
    my $self = shift;

    my $rc = 1;
    foreach my $child (@{$self->children})
    {
        $rc = $child->walk_and_do;
        last unless $rc;
    }

    unless ($rc)
    {
        $rc = $self->do_my_stuff;
    }

    return $rc;
}

[download]
I think that the first is clearer and cleaner. There are less levels of indentation. Torvalds says in his style guide that there should never be more than 3 levels of indentation. If you're constantly checking codes and values, that simply won't work. I often find it harder to read code with 1 entry and 1 exit vs. 1 entry and N intelligently-designed exits.

Exit when appropriate, not when some schmuck with a bunch of letters after their name tells you. I work for a living.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Replies are listed 'Best First'.
Re: Re3: A matter of style
by l2kashe (Deacon) on Feb 14, 2003 at 18:34 UTC 
    # Your code
# Pure
sub walk_and_do
{
    my $self = shift;

    my $rc = 1;
    foreach my $child (@{$self->children})
    {
        $rc = $child->walk_and_do;
        last unless $rc;
    }

    unless ($rc)
    {
        $rc = $self->do_my_stuff;
    }

    return $rc;
}

# Same function, single return, just as clear (for me)
# ala TIMTOWTDI
sub walk_and_do {
   my($self,$flag,@return);
   
   $self = shift;

   for ( @{$self->childer} ) {
      (last && $flag = "$_->{err}") unless $_->walk_and_do;
   }

   if ($flag) {
      @return = ('0', "$flag);

   } else {
      @return = $self->do_my_stuff || ('0', $self->{err});
   }

   return(@return);
      
}# END sub walk_and_do

    [download]
    I don't want this to spiral downwards. What we are talking about here is PERSONAL style. For me its easier to maintain a single entry and single exit. Ill deviate when appropriate, but I tend to try and keep things straightforward. It makes it easier *for me* to maintain and extend my code.

    /* And the Creator, against his better judgement, wrote man.c */
[reply]
[d/l]
[reply]

        Excellent link. I think the following quote from it is extemely illuminating. (And rings a particular bell for me, the reformed pascal programmer :-)

          The canonical example of the loop-and-a- half problem is precisely the one that Knuth describes: reading a set of input values until some sentinel value appears. If the basic strategy is expressed in pseudocode, the problem has the following solution: 

                    loop
            read in a value;
            if value = Sentinel then exit;
            process the value
          endloop;

          [download]

          In this example, the loop/exit/endloop statement is an extension to the Pascal repertoire and represents a loop that is terminated only by the execution of the exit statement in the interior of the loop body. The loop/exit/endloop extension makes it possible to express the algorithm so that the input value is read in from the user, tested against the sentinel, and then processed as necessary.

          The loop/exit/endloop approach, however, offends the sensibilities of many computer science instructors, who have learned through their experience with Pascal to "unwind" the loop so that the test appears at the top of the while loop, as follows:

                    read in a value;
          while value != Sentinel do begin
            process the value;
            read in a value
          end;

          [download]

          Unfortunately, this approach has two serious drawbacks. First, it requires two copies of the statements required to read the input value. Duplication of code presents a serious maintenance problem, because subsequent edits to one set of statements may not always be made to the other. The second drawback is that the order of operations in the loop is not the one that most people would expect. In any English explanation of the solution strategy, the first step is to read in a number, and the second is to process it by adding it to the total. The traditional Pascal approach reverses the order of the statements within the loop and turns a read/process strategy into a process/read strategy. As the rest of this section indicates, there is strong evidence to suggest that the read/process strategy is more intuitive, in the sense that it corresponds more closely to the cognitive structures programmers use to solve such problems.

          Loop Exits and Structured Programming: Reopening the Debate

        Thanks very much for the link. That a keeper.

        ---
        demerphq


[reply]
[d/l]
[select]

In Section Meditations