Beefy Boxes and Bandwidth Generously Provided by pair Networks chromatic writing perl on a camel
P is for Practical
 
PerlMonks  

Re: brian's Guide to Solving Any Perl Problem

by WuWei (Initiate)
on Jul 27, 2004 at 04:54 UTC ( #377655=note: print w/ replies, xml ) Need Help??


in reply to brian's Guide to Solving Any Perl Problem

In general, it's a good idea to declare variables using my instead of using a global or using local. It forces namespace and scope awareness and eliminates pernicious bugs caused by same-named variables with different scope. Practically anything you can do with a local or global variable, you can do with a change in design using my, and you'll get a much more robust design.

Also, in general, avoid exporting variables from modules. Exporting methods can sometimes be OK, although I still think it's better to say

use Foo::Bar; ... my $barian = Foo::Bar->baz();
so the method's origin is clear.

Variable and method names should be communicative of the intended use; it's better for a name to be long and communicative than short and cryptic.

Document, document, document.

Also: I'm astonished no one's mentioned using functional spec's and test suites before now. (Visit this Joel Spolsky article and scroll down to the second headline, "Painless Functional Specifications," for information on the former; perldoc Test::Harness and perldoc LWP::UserAgent for details on the latter, and on user agents which are also an enormous boon to web developers seeking a means of testing functionality and sounding the alarm when things go wrong.) Writing a spec before the program saves loads of time and heartache, as well as keeping the MBA's and the techies on the same page. Similarly, fleshing out the spec into a test suite before any code gets written -- and continuing to flesh out the test suite while coding -- reduces the likelihood of bugs, increases confidence in the final product, and makes a predictable timeline actually possible. Ideally, you want to test as high up the call chain as possible, drilling down into the nitty gritty only when -- and to the extent that -- the need presents itself.

There are even times where it can be helpful to write a tiny program whose specific purpose is to test the syntax or the effect of some (for you) uncharted Perl functionality. I did this in my formative Perl years and it saved me an enormous amount of time.

Oh, and also it helps -- particularly if you're working in a country whose primary language is English -- not to comment your code in, say, Croatian. (Don't laugh, I actually inherited a project some years ago containing some sections of code in which this had been done!)


Comment on Re: brian's Guide to Solving Any Perl Problem
Select or Download Code
Re^2: brian's Guide to Solving Any Perl Problem
by Anonymous Monk on Jul 31, 2004 at 07:19 UTC
    Along similar lines as that last point, I'd find myself (particular for CPAN modules) always writing my APIs in American English, despite being in Australia.

    It just makes life similar if everybody uses the same spelling for classes and methods. It's a swallowing your pride thing.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://377655]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (6)
As of 2014-04-21 05:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (490 votes), past polls