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 */

In reply to Re: Re: A matter of style by l2kashe
in thread A matter of style by Ryszard

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.