Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

perrin (4270)

perrin
  (email not shown publicly)

Perrin is a contributor to various Perl-related projects like mod_perl, Template Toolkit, and Class::DBI. He is a frequent speaker at OSCON, YAPC, and ApacheCon, and a contributor to several perl-related books.

Journal of perrin (4270)

Wednesday April 29, 2009
04:11 PM

Do you order your sub definitions?

[ #38892 ]

Just curious. I usually try to arrange them so that most calls to other subs in the same file are forward references and the internal subs are defined close to where they are called most prominently. Does anyone else think about this?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • And if I understand what you're saying, I do the same thing.

    • Hi Folks

      Alphabetical order here.

      And with a comment on the sub's closing } to re-iterate the name, as in:

      } # End of marine.

  • Because I interleave my method POD in between the methods, I usually order them in human-learning order.

    Constructor
    Accessors
    Main Methods
    Support Methods

    • I do almost the same. I love having my POD right next to the methods so it's easier to update when I update the method. So my documentation usually prescribes my method order which usually works out to be the best way to orgainze them, at least for me.

  • But as time goes by I get less inclined to. POD gets written down after the __END__ and the module gets written up in learning order, but in the body of the code, stuff falls where it will (usually near to where it got extracted from) and etags claims its own.

    If I'm coding in Ruby, it goes 'public, protected, private' (and when I do sort perl methods, that's the kind of gradient I go with as well, even though perl doesn't make those distinctions.)

    • Same.  Between etags and imenu (*), I can find things quickly enough without putting them in any particular order.

      PS -- Thanks to use.perl's craptastic version of "HTML formatted," which doesn't allow PRE or some equivalent, the only way to post code seems to be to post the whole thing as "Code."

      (* with some help)

      (defun my-imenu-fixup (list)
        (mapcan (lambda (x) (if (consp (cdr x)) (my-imenu-fixup (cdr x)) (list x)))
                list))

      (defun uniquify (list)
        (let ((h (ma
      • ... or >ecode<

        • Heh. I tried the standard HTML tags [w3.org] "PRE" and "CODE," but didn't think to add an "e." I assume the rationale is something like "it's better break our 'HTML formatted' by adding an 'e' to the tag name than to break it by rendering 'CODE' or 'PRE' in a way that differs from the standard." There are levels of suck to which the only appropriate response is to point and laugh.
  • I do that in "scripts", basically write what I want to happen, then fill in the details. I usually put a main function at the top too, as the entry point, followed by exit just to be explicit about what's happening (to indicate that there's no "inline" code between subroutine definitions).

    In modules, I'd tend to use the "learning-order" that people mentioned.