My own take [LWN.net]

My own take

Posted Oct 10, 2005 21:12 UTC (Mon) by felixfix (subscriber, #242)
Parent article: Book Review: Perl Best Practices (NewsForge)

I have a copy, and have almost finished reading it. Some of it strikes me as pure busy work, unworthy of being called Best Practices. For instance, he likes "{" on the end of the line introducing a block, "}" on a line by itself, indented to match the "{" line, and so far so good. But then he wants "else {" on a line by itself, indented to match the "}" line, on the basis that "else" is important and should be at the beginning of the line to be in a consistent position. But the construct "} else {" would also be in a consistent position, only differing by having two (consistent) characters in front of it. This seems like a strange best practice.

He also disparages using two double quotes ("") for the empty string, as double quotes are for interpolated strings with embedded variables. But don't use two single quotes (''), as that could be mistaken for a single double quote. Never mind that Perl is pretty good at detecting unterminated strings, and usually tells you where they started. What he wants is the horrible "q{}". Ditto for a single space.

He prefers "for (list) {}" rather than the C "for ($i = 0; $i < end; $i++) {}" because it is not obvious to novices. But he ignores what to do with humonguous lists with millions of entries; is it going to create a huge second copy or not?

There's a lot of nice stuff in this book. But there's enough trivial poorly rationalized stuff to make it less than sterling. I usually buy two copies of good books, one for the office and one for home. One copy of this is enough.

(Log in to post comments)

My own take

Posted Oct 10, 2005 22:44 UTC (Mon) by Dom2 (guest, #458) [Link]

With regards to people using C-Style for loops in Perl, that's usually a "red flag" in any code review of mine. There's no copy made of the list. You simply iterate through each value. Using C style for loops without a comment to say why is a sign that the person writing the code doesn't understand good, idiomatic Perl.

As to the stuff like brace style, I think he's made a good middle of the road choice and tried to explain his standards. He's obviously not going to please everybody, though. But he doesn't try to. He explains clearly that you have to pick your own style and use it *consistently*. To be honest, the style itself is less important than making sure it's used consistently. And that applies to any language, not just Perl.

I strongly recommend listening to the interview he did recently about the book:

http://www.perlcast.com/audio/Perlcast_Interview_003_Dami...

-Dom

My own take

Posted Oct 10, 2005 23:04 UTC (Mon) by felixfix (subscriber, #242) [Link]

Here is his rationale for putting "else {" on a line by itself:

A cuddled else [the "} else {" construct] is no longer in vertical alignment with its controlling if, nor with its own closing bracket.

This is just so much nonsense, a rationale made up after the fact because he likes the looks of it. "} else {" is no harder to spot, or line up, than "else {", and anyone who thinks "} else {" is harder to see than either "}" by itself or "else {" by itself is fooling themselves.

I don't pick on this just to be picky. The problem is there are many "best practices" in this book which seem just as trivial to me, as if he wanted to make the number of best practices come out to an even 256 and had to scrape the bottom of the barrel to get them.

My own take

Posted Oct 11, 2005 12:45 UTC (Tue) by carcassonne (guest, #31569) [Link]

I do not understand why you focus on 2 chapters out of 19 when describing this book.

What about Tabular Ternaries ?

Multi-Contextual Return Values ?

Smart Comments to automate progress indicators ?

Test Harnesses ?

Memoization ?

Etc, etc... (short of time here to list more)

There's a LOT more in this book than the use of curly brackets and single or double quotes for strings. Come on.

My own take

Posted Oct 11, 2005 9:49 UTC (Tue) by NAR (subscriber, #1313) [Link]

But the construct "} else {" would also be in a consistent position, only differing by having two (consistent) characters in front of it.

My problem with the '} else {' construct is that it breaks the syntax folding of vim, it makes one fold for the whole 'if' instead of two separate folds for the 'if' and the 'else' part. This is a really practical reasoning :-)

Never mind that Perl is pretty good at detecting unterminated strings, and usually tells you where they started.

Not to mention that if there is syntax highlighting in the editor, the unterminated string will be quite clearly shown before the perl executable has anything to do with the source file.

Bye,NAR