> Out of curiosity, why this rule?
>
> When taking programming classes in college, it was drummed into us that
> having a data dictionary at the top of a scope was a good habit, and
> it's something that I've generally done with the Perl I've written.
>
> Several people on this list have discouraged the habit. How come?
Because Perl isn't COBOL <g>
As a Perl programmer, I do tend to declare at first usage, but I
disagree strongly that it defeats the purpose of strict -- in my mind
the single most glowing feature of strictures is that it catches typos
... Especially really COMMON typos that I make (your flubs will vary)
my %option = (.....)
Pet_it() if $optoin{fuzzy};
Without strict, I'd be bald as a cue-ball from tearing my hair out
looking for every misspelling of option.
When I was a younger Perl programmer, I did have the habit of
declaring all my variables near the top of the scope block -- a habit
I carried over from C. I also wrote a lot of for ( $ii = 0 ; $ii < 10
; $ii++ ) and other Bad Habits.
By doing that, I found it tends, through human laziness, to be a
write-only field. As my code morphs and finally gels, I was finding
that I had a ...
my qw / $this $that $the_other @why_wont_this_work %temp_hash
%temp2_hash %temp3_hash /;
... that goes on for three lines, of which, in the end, only three
variables were actually used.
Another benefit -- by keeping the declaration close to their actual
instantiation - you make the job of cutting-and-pasting and
rearranging code just a little bit easier. And making code
housekeeping easier means you're more likely to do it, and that will
save you a LOT of time six months when you come back to this program
and have forgotten what it was for.
I'm pushing forty. My boss, who is much younger than me, will say,
"Remember that module you wrote that does blahblabhlah? We need to
add in a feature to do bliz bliz blz ... " And I will honestly reply
.. "I vaguely remember writing a module, something like that .. What
does it do?" I *have* to write exceptionally clear code, because
tomorrow I won't remember what I wrote yesterday <g>
So, here are two of *my* survival skills for aging programmers:
1. Time spent typing is not wasted. Never, *ever* abbreviate.
(there are a few exceptions to this in my book -- there are some
idioms so common, that they're self-apparent).
2. Use case in a consistent way to communicate additional
information. I don't want to open the worm-can of "is case
sensitivity morally reprehensible" - but - as long as we *have*
it, let's *use* it to our benefit.
For example:
Instance accessor/mutator functions have singular
forms of nouns in lowercase.
$person->age(29); print $employee->pay_rate;
Instance methods that perform some change have verb forms in lower
case. $catalog_item->deliver; $trunk_group->disable;
Class methods have uppercase forms: Employee->Create();
Functions/methods that return a list have plural noun forms:
$division->Employees; $person->email_addresses.
Well -- enough philosophy for one day ...
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Lawrence Statton - [EMAIL PROTECTED] s/aba/c/g
Computer software consists of only two components: ones and
zeros, in roughly equal proportions. All that is required is to
sort them into the correct order.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
