On Mar 8, 2009, at 1:29 PM, Ron Bergin wrote:
On Mar 4, 4:46 am, [email protected] (Jerald Sheets) wrote:I really think you're doing yourself a disservice by just throwing your program commands on lines, not indenting according to best practices. It makes your code unreadable, and can make it very hard to debug the more involved your programs get.[snip]Consider picking up Damian's book: http://oreilly.com/catalog/9780596001735/index.htmlIt'll serve you well and is a must have for the serious perl programmer.I agree, however your code as shown below doesn't follow "Perl Best Practices". You use improper indentation, and failed to use vertical whitespace making it harder to read/follow.#!/usr/bin/perl -wIt's better to use the warnings pragma, instead of the -w switch
Thank you for some of your suggestions, I'll take those into account. Consider also that like I said in the message, the code was untested and not run. It was a "quick and dirty" from a browser-based email with some suggestions for readability. Surely, the multiple iterations over the various values would not be necessary, but the point of the suggestion was for readability and readability alone. Whether fully complying with Damian's book or not, you cannot argue the difference in readability (my point of the messages) in comparison to what was offered. When I get past leisurely using perl (I've been "in the family" for about 8 months now) and get a chance to use it in production more, I'm sure I'll be a little more familiar with the various indentation styles and issues surrounding each.
However on the -w switch, here are Damian's words: 18.8. Warnings Always turn on warnings explicitly.If you're developing under Perl 5.6 or later, always use warnings at the start of each file. Under earlier versions of Perl, always use the -w command-line flag, or set the $WARNING variable (available fromuse English) to a true value.
Perl's warning system is invaluable. It can detect more than 200 different questionable programming practices, including common errors like using the wrong sigil on an array access; trying to read an output stream (or vice versa); leaving parentheses off ambiguous declarations; runaway strings with no closing delimiter; dyslexic assignment operators (=-, =+, etc.); using non-numbers as numbers; using | instead of ||, or || instead of or; misspelling a package or class name; mixing up \1 and $1 in a regex; ambiguous subroutine/ function calls; and improbable control flow (e.g., returning from a subroutine via a call to next).
He appears to insinuate they are interchangeable with the phrase:"always use the -w command-line flag, or set the $WARNING variable (available fromuse English) to a true value."
How would one know or be aware of anything different? Where would I find that information? I looked throughout the book, and this was the only reference to warnings I could find. Is there another reference you are citing? Where can I find it?
Thanks again for the input. Every little bit helps. --j
PGP.sig
Description: This is a digitally signed message part
