|The stupid question is the question not asked|
Re: Sensible ordering of 'use' (if any)by davido (Archbishop)
|on Nov 01, 2011 at 15:48 UTC||Need Help??|
I've seen alphabetical, but I tend to do it like this:
To me the idea is to start with the generalities that may be most applicable to all scripts, and then work my way toward the most specific modules to this particular application. At the same time I try to cluster modules that work together... together.
As I think about it, that's sort of a bottom up approach. Perhaps I should reverse the order to add clarity in reading the source, but I'm in this habit, and would probably only change if strong benefits are shown to be embodied in another approach.
One caveat is that there are a few modules which specifically state that you must use this one before that one. Inline::Files has to be listed before Inline::C, for example. In such cases it's important to # document the need, because today it may be obvious but tomorrow you (or I) will forget.
If I'm using a module for one small portion of a program, and not specifying an import list, I often # comment on what specific need this module is filling. That way if the program changes and that use is removed, I can quickly identify the module that is no longer necessary.
That's a habit that came from C, where it's common to list a whole bunch of header files to #include, and then quickly forget why they're being included.
I've considered # documenting along side my module uses which ones came from core, which I installed from CPAN, and which I wrote myself, but that level of documentation is more ambitious than I've been able to self-enforce.
I just checked, and unless I'm missing it, Perl Best Practices is silent on the issue of order of using modules. I recently re-read the book too, but that still doesn't mean I haven't forgotten. :) I wonder if the omission is because it doesn't matter, because it's too obvious to mention, or because it just wasn't considered.