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

I hear where you are coming from here, but I find some idioms to very helpful, such as the comment ending a closure. Not so much because I have to, but because I like to. It comes in very handy for me to quickly extend a given sub routine/method, if I can (in vi)
/# END sub blah

That being said, I don't do it because it is part of nomenclature to do it that way, I do it because that is my style, and it makes me more efficient when coding. Granted there are always people who follow a particular mindset/way of doing something because then they dont have to think, but there are also times when people who walked the same "path"/encountered the same problems (large code base, poorly written code) and have managed to find resonable solutions to those problems, and disseminated that info. I always question what is given to me, but sometimes their reasoning makes sense. On the other hand, there was a thread not too long ago about the idiom
$self = ref($class) || $class;
What was wrong with it, and what was right and the whys of the scenarios. I now understand what people think, and have altered a sizeable chunk of code to use the appropraite structure. If that thread hadn't been there I would have continued on blithly thinking my code was clean, when in fact it was cluttered. All because I had read it in an O'Reilly Perl book and thought it was the Right Thing(TM). So what I am trying to get at here is, its great that you are questioning the norm in terms of what you are righting, be careful not to blithly(sp?) write off a particular notation because you want to be an individual

On the actual thread at hand, I also do the same as the original poster,
begin sub, validation, algorithm, return
I also tend to attempt to make sure I only have one return, and to nest my code in such a way, as to get to a single return line, as opposed to returning from multiple points. I also always attempt to name what is going to be returned "return" with the appropriate sigil. Which again makes me more efficient as I can quickly scan a body of code, and determine exactly where my return value is being built, as opposed to having to guess, whats going to end up coming back

If I am going to return an array for example I always populate @return, if I encounter errors, I clear the array, set 0 to some NULL val, and then elem 1 to an error string. Then the calling function need only test elem 0 for truth, or what have you, and respond appropriately.
With this style I find it easier to write quasi concise routines (depends on what you are doing), with a fairly limited testing structure, which in turn leads to faster, easier to debug code. Which I like :)


/* And the Creator, against his better judgement, wrote man.c */

Replies are listed 'Best First'.
Re3: A matter of style
by dragonchild (Archbishop) on Feb 14, 2003 at 17:30 UTC
    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.

[reply]
[d/l]
      # 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]
Re: Re: Re: A matter of style
by revdiablo (Prior) on Feb 14, 2003 at 21:59 UTC

    Focusing only on the #END foo markers, I find it interesting that you mention vi. Personally, I find using % to bounce between openning and closing braces much nicer than having to 1) clutter my code with countless #END foos, and 2) think about the foo to #END foo mapping when looking for the end of it.

    Of course, as you mention in another post, this is all personal style. Sometimes it's unfortunate that everybody thinks their own style is the best. :)

[reply]
[d/l]
[select]

In Section Meditations