"Ben Scott" <[EMAIL PROTECTED]> writes:
> Personally, in the proper context, I find this:
When writing code which will be used, looked at, modified, and
maintained by no one else, doing whatever makes you happy and more
efficient makes sense, and is more efficient and expedient.
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. This makes the entire
group more eficient. The personal likes and/or dislikes of anyone
person may or may not bother anyone else in the group.
> @foo = split m{blah};
>
> to be easier to read and comprehend at a glance than this:
>
> @foo = split (m{blah}, $_);
I find both of these bothersome :) *I* prefer:
@foo = split (/blah/);
or: @foo = split (/blah/, $actualVariableName);
The former implies $_, which need not be explicitly stated in this case.
The latter clearly denotes where you're getting your data from.
$_ has a *lot* of magical properties which can really screw things up,
especially in cases like:
map { grep { ... $_ } $_ } @foo;
Which $_ is which, and where is each getting it's data from? This is
where the use of named variables I find to be better than just
depending upon built-ins like $_.
> 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 (which should also be my'ed into the
proper scope :)
> I don't arbitrarily assign to $_ and use it at random, the way some
> people do. And I do make use of parenthesis, braces, and such, even
> when they are not needed, when I find it makes the code clearer. But
> I also leave them out when I find it makes the code clearer.
No arguments with that. In general, IMO, clarity is of the utmost
importance. There are many "best practices" which can help aid
clarity though. I find one such practice is to always use func(args)
because it makes it blatantly obvious you're calling a function.
(perhaps the one exception is with print, but even then, I find myself
very often using it there too. To me:
print (join("\s", "Some text", func(args), "more text",),
"\n"
);
is far more readable than
print join " ", "Some text", func(args), "more text", "\n";
In the former, if I need to add "stuff" to the join, it's blatantly
obvious where it goes. In the latter, it is not.
> For a slightly less contrived example, take a script which trims
> leading and trailing whitespace from each line in an input file. I
> already have one implementation, and I just wrote up another one.
[...]
> Assuming the reader is familiar with the language, which do you
> think will be easier/quicker to comprehend?
Both of these hurt my eyes! :)
This one is short and sweet:
> #!/usr/bin/perl -wp
> s/^[\x20\t]*//; # trim leading space
> s/[\x20\t]*$//; # trim trailing space
but I'd rewrite it as:
#!/usr/bin/perl -p
s/(^\s*|\s*$)//g; # trim leading/trailing whitespace
For a script which optionally took stdin, I'd write it as:
#!/usr/bin/perl -w
use English;
my $file = shift;
my $FH;
if (!$file) {
*FH = *STDIN;
} else {
open(FH, "$file") || die("Could not open $file: $ERRNO\n";
}
while (my $line = <FH>) {
$line =~ s/(^\s*|\s*$)//g; # trim leading/trailing whitespace
print("$line\n");
}
close(FH);
> It may be true that someone who *isn't* familiar with Perl would
> find it easier to puzzle out the meaning of the longer version.
I'm fairly comfortable with perl. I could puzzle out the meaning
fairly easily. And I'll even concede that as far as most perl, it's
pretty good. But, as is true I'm sure even with my own code, there's
always room for improvement :)
(/me waiting for Kevin to pipe in here in 4...3...2...1... ;)
> But I don't find that a particularly compelling argument.
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 :) The easier you make it up front to read your code and
discern your mindset, the less time it take the maintainer in 6
months. Many times, that future maintainer is *you* :)
> I write Perl programs with the assumption that the reader
> understands Perl, the same way I am assuming readers of this message
> understand English. :)
Ahh, yes. But as the superintendent of the Lawrence, MA, School
system has recently shown, even those who *claim* to know the
language, often times are just fooling themselves. Just "axe" him :)
> This may mean Perl, as practiced, is harder to learn than a language
> which is more rigid and always verbose.
I think perl is incredibly easy to learn if you learn from a good
source. The documentation is one such source. Other people's code is
most often NOT a good source!
> 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? Or are you saying that there may be an approach to learning
Unix without Emacs ? In which case, I declare you a heretic and cast
aspersions and insults in your general di-rection! ;)
--
Seeya,
Paul
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
