On Mon, Dec 06, 2010 at 08:45:01PM +0200, Shlomi Fish wrote:
> On Monday 06 December 2010 19:49:44 Abigail wrote:
> > On Mon, Dec 06, 2010 at 07:34:35PM +0200, Shlomi Fish wrote:
> > > Now I think that some of my style/best-practices suggestions are an
> > > improvement and I'd like to pursue them.
> >
> > And I'm strongly against that sentiment.
> >
> > I really do think p5p, and hence the documentation, should *not* have a
> > style preference, or have some form of "best practice" (nor do I believe
> > you'll find consensus on what "best practice" will be). Style guides,
> > coding standards, best practices, or whatever you want to label it only
> > gives rise to coding police, and it's only fuel to people who only answer
> > questions on usenet or Perlmonks with "well, for starters following these
> > as these rules", regardless whether that helps answering the question
> > or not.
>
> Well, I don't frequent either Usenet or Perlmonks, but let me answer. (For
> the
> record, I help a lot on IRC and on mailing lists.) I've collected a longish
> list of bad practices to avoid (from PBP and other sources) here:
>
> http://perl-begin.org/tutorials/bad-elements/
>
> Now, I've specifically tried to make it as non-controversial as possible and
> avoided recommendations that are a matter of taste, and can be done this way
> or another.
>
> If you think all style guide / best practices / etc. are not helpful, will
> you
> accept code that:
>
> 1. Lacks all indentation?
Unlikely.
>
> 2. Has magic numbers such as:
>
> my $n = uc($_[3]);
Depends on the usage. I don't have much problems with:
$minutes = 60 * $hours;
And for manual pages, due to line-length restrictions, I rather accept
a numeric literal, than a descriptive name that causes the line to wrap
on my terminal.
> 3. Has comments or even identifiers in a non-English language?
Depends on the environment.
> 4. Has duplicate code?
Maybe. I do copy-and-paste at $WORK every now and then. Sometimes, the cost
of copying is less than the cost of abstracting. It's a trade-off.
For documentation, I'm even more willing to accept duplicate code.
> 5. Has inconsistent tabs and spaces and looks differently aligned on many tab
> widths?
Personally, I never use tabs, unless the syntax demands it (like Makefiles).
> 6. Has non-descriptive variable names? Reportedly
> http://en.wikipedia.org/wiki/Daniel_J._Bernstein uses many single-letter and
> double-letter identifiers in his code.
Certainly. $i, $n, etc, I use often. For documentation, $foo, $bar, and
friends are often acceptable.
But avoiding really bad techniques is a far cry from enforcing a certain
style. Rejecting code that lacks all indentation isn't the same as changing
identation in existing documentation to what someone considers the optimal
indentation width.
To go back to your suggestions that started this long thread, I don't think
any of the proposals fell into your points 1-6.
> I know none of these will be acceptible to me, because they are not a matter
> of taste, but rather objective measures of the internal quality of the code.
>
> However, there are a lot of style debates, like which indentation style to
> use, or whether to do my ($self, $args) = @_; or my ($self, %args) = @_; or
> whether one should avoid using "unless" instead of of "if (!)" altogether
> (which I do), or whether one should avoid trailing conditionals (which I also
> avoid), etc. etc. These are still a matter of preference and mostly amoral,
> and are not covered in my document.
>
> Now the question is which category making the code strict-safe or using
> lexical filehandles belongs to. People have given good arguments for both of
> these for many years now, so I think they belong in the things that p5p will
> necessitate in code examples (unless someone has a compelling argument why
> they are not a good idea).
Note that lexical filehandles have been possible since October 1994, with
the release of Perl 5.000. It wasn't until the release of 5.6.0 with
the introduction of autovivifying that people actually started using them -
before then, the extra line of code required apparently didn't offset the
benefits. I refuse to believe people wrote bad code for a dozen years
(counting pre-perl5 as well).
Do we have to document autovivifying file handles? Certainly. Do we have
to show how to use lexical filehandles? Yes. Do we have to label code that
uses bare file handles as bad, unwanted or outdated? No.
As for strictness, let me reiterate my opinion. The majority of the examples
of the documentation are code fragments. For brevity reasons, it doesn't
state "use strict;" or "use warnings;". Nor does it declare a package, or
starts with a she-bang line. Often, it doesn't read any data, nor writes
any output. That's all assumed to be "somewhere". Just as declaring used
variables with 'my'. After all, if someone wants to copy lines into his
program, only he knows where scopes end or begin.
Now, if you have some examples where symbolic references are used (and the
examples aren't about symbolic references themselves), you're less likely
to get opposition from me if you propose a patch to either eliminate the
symbolic reference, or a line that points out a symbolic reference is used.
But just blindly slapping 'my' everywhere isn't something that gets me
cheering.
Abigail
