On 9/13/07, Paul Lussier <[EMAIL PROTECTED]> wrote:
> When writing code which will be used, looked at, modified, and
> maintained by a group of people, it is best to agree upon and strictly
> adhere to a common set of coding standards.
Yes. But when the designated group of people is "all of humanity",
the problem of agreeing on said standards becomes difficult. :)
> I find both of these bothersome :) *I* prefer:
>
> @foo = split (/blah/);
Er, yes. "blah" in this case was meta-syntactic, and I was still
thinking of the first example in this discussion, which had LTS
(Leaning Toothpick Syndrome). I will use // if the regexp doesn't
suffer from LTS. I use m{} or s{}{} when the regexp otherwise
contains slashes.
> @foo = split (/blah/);
> @foo = split (/blah/, $actualVariableName);
> The former implies $_, which need not be explicitly stated in this case.
Right. That's exactly what I was saying. ;-)
> map { grep { ... $_ } $_ } @foo;
>
> Which $_ is which, and where is each getting it's data from?
Like I said, I use things like parenthesis, braces, named variables,
etc., liberally when I find the meaning/intent is not obvious in
context. But it's a case-by-case call, not an absolute, inviolable
rule.
"A foolish consistency is the hobgoblin of little minds." -- Ralph
Waldo Emerson
As a completely non-contrived example, here is an illustration of
when I think implicit use of $_ is very appropriate. It's from a
Squid log analysis tool I wrote, where I wanted to condense the MIME
content type into something smaller and more appropriate for a log
report. Here's the code (as usual, view in a monospace font to get
this to line up properly):
sub condense_type($) {
# condense a MIME content type to something shorter, for people
$_ = $_[0];
s{^text/plain$} {text};
s{^text/html$} {html};
s{^text/css$} {css};
s{^text/javascript$} {jscript};
s{^text/xml$} {xml};
s{^text/} {};
s{^image/.*} {image};
s{^video/.*} {video};
s{^audio/.*} {audio};
s{^multipart/byteranges}{bytes};
s{^application/} {};
s{^octet-stream$} {binary};
s{^x-javascript$} {jscript};
s{^x-shockwave-flash$} {flash};
s{\*/\*} {stars}; # some content gets marked */*
return $_;
}
I could have used a regular named variable (say, $type) and repeated
"$type =~" over and over again for 14 lines. I believe that would
actually harm the readability of the code. I find it clearer with use
of implicit $_, because it puts the focus on the fact that I'm doing a
bunch of transformations on the same thing, over and over again.
As a counter-example from the same script, here's something using
explicit names and grouping which isn't strictly needed, because I
find it clearer:
sub condense_size($) {
# consense a byte-count into K/M/G
my $size = $_[0];
if ($size > $gigabyte) { $size = ($size / $gigabyte) . "G"; }
elsif ($size > $megabyte) { $size = ($size / $megabyte) . "M"; }
elsif ($size > $kilobyte) { $size = ($size / $kilobyte) . "K"; }
return $size;
}
>> Explicitly specifying $_ over and over again just clutters up the
>> code with pointless syntax. It's one more thing my brain has to
>> recognize and process.
>
> Right, which is why you shouldn't depend upon $_ in these contexts and
> explicitly state a variable name ...
A named variable would be *two* more things. ;-)
> s/(^\s*|\s*$)//g; # trim leading/trailing whitespace
Er, yah, that would be even better. Not sure why I didn't just use
s/// with /g when I wrote that the first time around.
(The actual script in my ~/bin/ has several lines of comments
explaining certain design decisions, but that's one one of them.)
> my $file = shift;
You're using an implicit argument to shift there. ;-)
> The compelling argument is this: It should be blatantly obvious to
> whomever is going to be maintaining your code in 6 months what you
> were thinking
I do not think I could agree with you more here. The thing you seem
to be ignoring in my argument is that "clarity" is subjective and
often depends on context. :)
>> I write Perl programs with the assumption that the reader
understands Perl ...
>
> ... even those who *claim* to know the language, often times are
> just fooling themselves.
I'm not going to penalize the competent because there are others who
are incompetent.
>> Many say similar things about Unix. Or Emacs. :-) I'm don't argue
>> that one approach is right and the other wrong, but I do think that
>> both approaches have their merits.
>
> Which approaches are you talking about? Approaches to learning, or to
> writing?
Yes. :)
Let me restate: A pattern which is powerful and easy-to-use is
sometimes unavoidably non-obvious.
Or perhaps an example of a similar principle in a different context:
When invoking tar from a shell script, which of the following do you
prefer?
tar --create --gzip --verbose --preserve-permissions
--file=/path/to/file.tar.gz /etc
tar czvpf /path/to/file.tar.gz /etc
-- Ben
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
