Programming Rules in Perl 
Author Message
 Programming Rules in Perl

Quote:

>I'd like to have some recommendations and rules to start Perl programming in a
>correct way. I've seen some tutorials in Perl.

I'm new to Perl. It seems to me that the area that provides the most
scope for inadvertently inefficient code (not to mention unexpected
results) is in the Regex evaluation engine.

The "camel book" (Programming Perl by Wall, Christiansen and Schwartz)
explains the rules by which the regex engine operates.

If you're learning Perl for the purposes of writing CGI programs then
you should check out www.irt.org.
---
the e-mail address in the headers is bogus



Fri, 22 Jun 2001 03:00:00 GMT  
 Programming Rules in Perl
 [courtesy cc of this posting sent to cited author via email]

:I'd like to have some recommendations and rules to start Perl programming in a
:correct way. I've seen some tutorials in Perl.

Correct is a strong word.  But you might look at
    http://language.perl.com/style/
and
    http://www.perl.com/CPAN-local/doc/manual/html/pod/perlstyle.html

--tom
--
    No, I'm not going to explain it.  If you can't figure it out, you didn't
    want to know anyway...  :-)



Fri, 22 Jun 2001 03:00:00 GMT  
 Programming Rules in Perl
: I'd like to have some recommendations and rules to start Perl programming in a
: correct way. I've seen some tutorials in Perl.

With a few exceptions, all of these are "rules" in the sense that you
*can* break them, but you *shouldn't* break them until you've got a
thorough understanding of the language.

1) Every non-broken distribution of Perl comes with a wealth (literally)
of high-quality documentation.  It's far more comprehensive and of much
better quality than the documentation that comes with commercial
compilers costing hundreds or even thousands of dollars, and it's
*free*.  Get on intimate terms with it.  Learn to use the perldoc program
to look up functions and FAQs.  Build a mental overview of how it's
organized so that when you have a problem, you know where to look.  Every
so often, "water your camel" by picking a piece of documentation at
random and reading it.

2) Familiarize yourself with CPAN, the Comprehensive Perl Archive Network
(URL:http://www.perl.com/CPAN/).  One of the great things about Perl is
the number of reusable modules of Perl code that people have written.  
All those modules are available to you for free.  If you have a
non-trivial requirement, check to see if anybody's written a module that
would help you; that way you avoid reinventing the wheel and you get to
use code that's already been debugged and tested.

3) Always use the -w switch on your programs so that perl can alert you
to places where what you said might not be what you meant.

4) Although by default Perl doesn't require you to pre-declare the
variables you use, you shouldn't rely on this, and in fact you should
declare all your variables (usually with 'my', less often with 'use vars')
and use the 'strict' pragma (i.e. put 'use strict;' (without the quotes of
course) on the second line of your programs) so that perl will complain
about undeclared variables and "barewords" (pieces of literal text
appearing outside quote contexts).  It's all too easy to use two different
spelling variants of what's supposed to be the same variable name; 'use
strict' will help you catch this.

5) Whenever you call a function that does anything related to the file
system (opening a file, running an external program, renaming or deleting
files, etc.) *always* test to make sure the operation succeeded, and do
*not* allow your program to plow ahead if the operation fails.  When
printing diagnostic messages for file-operation failures, always use the
$! special variable to tell you *why* the operation failed.

6) If you're writing CGI programs, use the CGI.pm module that comes with
every distribution of Perl.  Do *not* write your own code to decode CGI
parameters, and do *not* cut-and-paste in someone else's code to do it.  
There are lots of buggy parameter-decoding routines floating around.

7) Use single quotes for strings that don't contain any variables to be
interpolated.  Double quotes should be a mental reminder that you *are*
interpolating variables.

8) Pay special attention to the proper syntax for addressing array

"$a[0]='first'".

9) Read the documentation on regular expressions (in perlre) and matching
operators (in perlop) several times; few people can pick it all up in one
reading.  Pay special attention to the different ways in which the
matching operators behave depending on whether they're used in scalar or
list context.  Learn when to use tr/// in preference to s///.

10) Read the documentation on the printf and sprintf functions, and learn
how to print fractional numbers to the proper number of decimal places.  
Read the FAQ that explains why the result of division may be 3.99999999
when you expected 4.0.

11) Learn all the various ways of quoting literal strings.  Your literal
strings should never suffer from "Leaning Toothpick Syndrome."



Sat, 23 Jun 2001 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. HELP needed on a simple Parse::RecDescent program (problem: some rules are matched twice)

2. HELP needed on a simple Parse::RecDescent program (problem: some rules are matched twice)

3. 21 Rules For Writing Secure CGI Programs

4. Sendmail rewriting rules in Perl?

5. Perl 5.6.1 under Cygwin: rules-dbm test fails

6. Using Perl for Makefile Rules

7. Perl rules - Pyhton drools

8. Count of items is EXCEPTION not RULE (was Re: Little perl annoyance #371: glob)

9. perl rule engine

10. Converting SQL89 YACC rule to Parse::RecDescent

11. Scoping rules for anonymous sub's?

12. ExtUtils::MakeMaker with non-standard installation rules?

 

 
Powered by phpBB® Forum Software