>>>>> "BR" == Bob Rogers <[EMAIL PROTECTED]> writes:
BR> sub BEGIN {
BR> no strict 'refs';
BR> for my $method (qw(option_definers additional_options
BR> man_p help_p usage_p)) {
BR> my $field = '_' . $method;
BR> i like "_$method" better.
BR> I don't; it's harder to see.
i find . hard to see and i like double quoted strings.
BR> This is boilerplate I lifted from somebody else's code; it strikes me as
BR> ugly, but I haven't changed it much, because I haven't thought of
BR> anything significantly better. This particular coder (I've forgotten
BR> who now) was fond of doing chains of accessors:
BR> my $obj = Some::Class->slot1($value1)->slot2($value2);
BR> I never do this myself, though I sometimes still take advantage of slot
BR> assignments returning the object.
i have seen that style and don't like it. but you can use Want.pm to
find out if the method is called in an 'object' context and return $self
in that case.
BR> my $self = bless {} => $class;
BR> i don't like using => like that.
BR> Why? I'm curious -- this is another inherited idiom, so I'm not wedded
BR> to it.
some like it as a cute comma. i only use => for key/value stuff (hashes
or paired values in lists/arrays). but it is not commonly used like that
so i don't do it.
BR> ever heard of vertical whitespace or comments?
BR> As a matter of fact, yes. Lower-than-normal comment density is part of
BR> what makes this an "early version" (though it's true that I never said
BR> so explicitly). Also, I don't use much vertical whitespace, because it
BR> makes less code fit on the screen.
get a bigger screen! :)
the tradeoff between vertical whitespace (which improves readability) vs
more lines on the screen is real. i just lean to more whitespace. i can
scroll up and down or use multiple windows in emacs just fine. :)
BR> use explicit returns. you may get burned with the return of last value
BR> thing. it is easier to see what is returned when you see 'return'
BR> As a matter of fact, this almost never gives me problems; I get burned
BR> more often by an overlooked 'return' that causes something later on in
BR> the sub to be skipped unexpectedly.
return is fairly visible. the problem is when you add code to a sub at
the end and forget to move the last expression down there. another
reason i do that is in stem where explicit empty returns are critical so
the rule is always use explict return.
BR> for some reason my emacs/supercite is screwing up the indent. but your
BR> habit of putting statement modifiers on the next line is unusual. i
BR> would put them on the same line if possible (that is if the combined
BR> line isn't too long). it just reads odd to me to see all those if's on
BR> the next line.
BR> For a long time, I resisted using statement modifiers at all. It is
BR> true that they are more compact, but they change the flow of control in
BR> ways that can make the code harder to read. I find it distracting that
BR> in
you want more lines on your screen and modifiers give you that. but you
lose some of that savings with your modifier on the next line. keep it
on one line if you can IMO.
BR> hairy_function_b(....)
BR> if hairy_function_a(....);
BR> the hairy_function_a gets called before hairy_function_b, in the reverse
BR> of the natural reading order. Combining them on the same line makes it
BR> worse, as it makes the true flow of control even less obvious.
so do hairy_function_a(....) and hairy_function_b(....).
BR> also using ||= will simplify many of those lines (as i did above).
BR> $cl_options->{usage} ||= sub { $self->pod2usage(2); }
BR> if $self->usage_p;
BR> This strikes me as still worse; there are two circumstances that could
BR> alter the effective flow of control, but they are being expressed in two
BR> different ways, still out of order.
but your code had a redundant (also slower) copy of
$cl_options->{usage}. and if you did ||= in all the places where it can
be used then it would be a clear idiom.
BR> Mind you, I do use "||=" and modifers on the same line from time to
BR> time, but I try to do so only if I think the intent is transparent. I
BR> use "||=" mostly for defaulting arguments to subs, and try to restrict
BR> same-line modifiers to cases where the branch will be taken almost all
BR> of the time. (Though I will confess to having taken some shortcuts in
BR> getting this code ready to post. As you can see, it's still not yet in
BR> CVS. ;-)
sometimes that stuff can be cleaned up with a different design. as i
said, i haven't gotten into that level here. i rarely seem to need ||=
and modifiers so i must be thinking differently than you about stuff
like that.
BR> sub _add_to_class_table {
BR> my ($self, $table, $class_visited_p, $class) = @_;
BR> if (! $class_visited_p->{$class}) {
BR> unless is nice there.
BR> I started using 'unless' until I wound up creating constructs like the
BR> following:
BR> unless (<some-expression>) {
BR> <some-code>
BR> }
BR> elsif (<some-other-expression>) {
BR> <some-more-code>
BR> }
that is the one place i drop unless and use if. but again, i rarely use
if/elsif trees. i find that my designs don't need them often. in 9k+
lines of stem i found 12 uses of elsif. i just naturally stay away
from that it seems. :)
BR> Sometimes I do that if I'm short on indentation, but I try to avoid
BR> nonlocal exits when I can. (But as you have seen, I am inconsistent
BR> here, too.)
i love early returns/next/last. wonderful way to simplify subs and
such. those lines are usually short and very clear. get them out of the
way and then don't hide the main logic.
BR> de morgan to the rescue!
BR> unless ($pod_file && -r $pod_file) {
BR> I agree that this reads better. But I would almost prefer:
BR> if (! ($pod_file && -r $pod_file)) ...
BR> due to the brain-bending mentioned above.
but see my comment on that.
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
_______________________________________________
Boston-pm mailing list
[EMAIL PROTECTED]
http://mail.pm.org/mailman/listinfo/boston-pm
