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?
And if I understand what you're saying, I do the same thing.
Re:No
Ron Savage on 2009-04-30T09:03:03
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
Re:Read order
mpeters on 2009-04-30T15:44:58
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.)
Re:I used to
educated_foo on 2009-04-30T09:41:45
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 (make-hash-table:test 'equal)))
(dolist (x list)
(puthash x t h))
(hash-table-keys h)))
(autoload 'imenu--make-index-alist "imenu" nil t)
(defun my-imenu-jump-to-function ()
"Jump to a function found by Imenu within the current buffer with
ido-style completion. NOTE: if a mode's imenu function does
something fancy (e.g. cperl's), this function breaks horribly."
(interactive)
(let* ((tmp (uniquify
(my-imenu-fixup
(remove-if
(lambda (x)
(or (string= "*Rescan*" (car x))
(and (member major-mode '(cperl-mode sepia-mode))
(or (string= "+Unsorted List+..." (car x))
(string= "+POD headers+..." (car x))))))
(save-excursion (imenu--make-index-alist))))))
(thing (assoc (my-icompleting-read "Go to: " (mapcar #'car tmp))
tmp)))
(when thing
(funcall imenu-default-goto-function (car thing) (cdr thing))
(recenter))))
(defun my-icompleting-read (prompt choices)
"Like `ido'. Hard to describe."
(or ido-buffer-completion-map (ido-init-completion-maps))
(flet ((ido-make-buffer-list (default)
(setq ido-temp-list choices)))
;; XXX - why do I have to do this?
(let (minibuffer-setup-hook)
(add-hook 'minibuffer-setup-hook 'ido-minibuffer-setup)
;; (ido-setup-completion-map)
(ido-read-buffer prompt))))
Re:I used to
Alias on 2009-04-30T15:19:36
... or >ecode<
Re:I used to
educated_foo on 2009-04-30T16:48:55
Heh. I tried the standard HTML tags "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.
