Advertisement
This is a terrific book.
www.amazon.com/gp/product/0596001738/
Sure to rub you at least partially the wrong way. I, for example, have always cuddled my curly braces, but Conway makes a convincing enough argument that I've actually switched.
Anyone else read it, love it, hate it?
www.amazon.com/gp/product/0596001738/
Sure to rub you at least partially the wrong way. I, for example, have always cuddled my curly braces, but Conway makes a convincing enough argument that I've actually switched.
Anyone else read it, love it, hate it?
posted by:
|
Anchorage
|
Advertisement
Advertisement
-
Unsu...
Re: Perl Best Practices
Mon, October 10, 2005 - 5:36 PMReading it, loving it, starting to try not to cuddle my elses anymore. Also tough is moving away from prepending my subroutine calls with an ampersand.
This is actually the book I've been waiting for. So often my Perl questions aren't, "How do I do this?" but, "How can I do this better?" -
-
Re: Perl Best Practices
Tue, October 11, 2005 - 10:03 AMSo is this book really that good? It looks exactly like what I've been looking for.
I just copies this from the sample chapter on subroutines on O'Reilly:
"Subroutines always receive their arguments in the @_ array. But accessing them via $_[0], $_[1], etc. directly is almost always a Very Bad Idea. For a start, it makes the code far less self-documenting:"
Whoops. I do that all the time.
Conway suggests this as a better alternative:
"my ($text, $cols_count, $want_centering) = @_;"
I might have to pick up this book. -
-
Re: Perl Best Practices
Sun, October 16, 2005 - 6:41 PMyeah, subscripting @_ is confusing, and can cause problems as the elements of @_ are essentially passed by reference (for some reason all the Perl books instead refer to this as "assigning to @_ modifies the values back at the caller"), so if you happen to assign to them you might get unexpected results.
whoever started spreading the idea that code is "self-documenting" should be smacked, though. yes, it's marvelous for programmers to name their variables something more clear than $a459z10, but if you name it $buf instead, it's demeaning to the idea of real documentation to think that's sufficient and you can dispense with comments and POD.
-
-
-
Re: Perl Best Practices
Tue, October 11, 2005 - 3:32 PMI actually bought the book at OSCON and was fortunate enough to attend Damian's talk on Perl Best Practices. The book is great and the talk was too but speaking with him during the breaks I could see how much thought he really did put into each of his recommendations. I consider myself still new to Perl but his advice has helped me improve my code. I did some of the things he mentioned already but his tips for making the code look cleaner have been a great help. -
-
Unsu...
Re: Perl Best Practices
Tue, October 11, 2005 - 8:24 PMI was actually just wondering how this book would affect new Perl programmers. I've been coding Perl full-time for years. Some of the recommendations made, like not subscripting @_, I've arrived at on my own thru experience. Some of his recommendations help to ease issues that have been irritating me for a long time. I think the longer you code Perl, the more relevant this book becomes.
-
-
Re: Perl Best Practices
Sun, November 13, 2005 - 2:25 AMI liked it so good that they quoted me *first* on the back. :)
-
Re: Perl Best Practices
Sun, February 5, 2006 - 7:51 AMI finally bought it. So far it's great and I picked up a few good tips, including this one:
When initializing arrays, do this
@rodents = ('Rat',
'Mouse',
'Squirrel',
);
Instead of this
@rodents = ('Rat',
'Mouse',
'Squirrel'
);
The extra comma isn't needed, but it's less error prone if you have to reorder or add to the array.
(pay no attention to the spacing, which was probably borked by tribe) -
-
Unsu...
Re: Perl Best Practices
Sun, February 5, 2006 - 7:03 PMYeah, either the Perl Cookbook or the Camel book mention that too (I can't remember which-- maybe both?).
-
