Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

what are all the things to be considered to write a effective perl script or module?

by balakrishnan (Monk)
on Feb 06, 2009 at 08:27 UTC ( #741828=perlquestion: print w/ replies, xml ) Need Help??
balakrishnan has asked for the wisdom of the Perl Monks concerning the following question:

Hi Monks,
What are all the things that i have to consider to write a effective perl script or module ?
Thanks.

Comment on what are all the things to be considered to write a effective perl script or module?
Re: what are all the things to be considered to write a effective perl script or module?
by Plankton (Priest) on Feb 06, 2009 at 08:37 UTC
Re: what are all the things to be considered to write a effective perl script or module?
by moritz (Cardinal) on Feb 06, 2009 at 08:46 UTC
    As the old saying goes "first make it run, then make it right, then make it fast".

    So code away, and if it becomes too slow for your application, you start to profile, and identify your bottlenecks.

    In many cases the choice of good algorithms and data structures buys you more than any micro optimizations.

    If you're still interested in micro optimizations, you'll find plenty of them discussed here at the monastery (for example with this search).

      As the old saying goes "first make it run, then make it right, then make it fast"

      I would prefer some sort of design first, preferably gathering requirements before that. Design of test cases to check that the specs are met. Specs that can be traced back to the requirements. Then write the code and test it, test it and test it. If the code does what it is supposed to do only then it is effective.

      That is interesting, I realize I tend to start from 'make it right, then make it run.' My reasoning for this is that I know how I want my code to look and where I want my values to be so I focus on putting things in the 'right' place. So when I have to go make it run I know where all the problems should be. I not saying that I don't have bugs, gods knows that I ain't true, but at least I should a general idea of where the problem is going to be.

      I see too many programs that were written to run first, and never bother going to the second step. The usual explanation being, if it runs, it must be right! :)

        I think that the "first make it run, then make it right" has two purposes: for one thing you can't check whether it's right if it doesn't run, and the second point is that beginners tend to write large pieces of code which is then hard to make run.
        The best approach depends on your problem. But for many problems a very good approach is to start with a running program that does nothing like what you need and then through many iterations make it into the program you want. And when I say a running program, there are occasions when I've started with:
        #! /usr/bin/perl -w use strict; print "Hello, world\n";
        and then evolved it into an entirely unrelated program. (I usually start with a slightly more complex standard template that does things like find the right library path, processes command-line arguments, and has POD stubs.)

        This approach may seem weird but it can work quite well. Particularly if you mix it with test driven development.

Re: what are all the things to be considered to write a effective perl script or module?
by Bloodnok (Vicar) on Feb 06, 2009 at 11:15 UTC
    IMO, the prime consideration must be to know and understand the problem you're trying to solve (with your script &/or module) - only then can you start to look at how you might implement it.

    A user level that continues to overstate my experience :-))
Re: what are all the things to be considered to write a effective perl script or module?
by leocharre (Priest) on Feb 06, 2009 at 15:15 UTC

    There's a huge diff between writing a script and writing a module.
    A script is possibly likely throw-away. A script can be something you put in your ~/bin - it might be a hack.
    A script will likely use modules.

    A module is a very freaking diff thing.
    A module implies multiple usage.
    Possibly distribution.
    With distribution comes documentation. And tests. And if you release something for other people to use, by god it better be tested (lookup test suites .. ./t) and documented. You don't want to release something that doesn't do what you say it does.

    What if your script uses "Carp" and one day your computer blows up. You don't want to find out it's because of Carp.

    Oh please no.. not carp..

    A script is code. A module is a work of art. Hopefully it has some value.

      I'm surprised nobody else hit on this yet.

      Granted I'm a Perl newbie, this seems like a very important distinction to make -- that a script is a whole different beast from a module.

      Even if you weren't planning on redistributing (and thus documenting, speed testing - beyond your own desires, etc.), the testing is essential for the module. And even if the Carp module doesn't blow up your computer, if it's defective it could cause some headaches in scripts you're trying to run with it.


      Anyways, in response to your original question, here's my $0.02. Whenever I need to write a script, a function, whatever, I've found it's definitely easiest to whip out some sort of text editor, and plan out what you need to do.

      Generally the process involves first listing what I want to do, and then what design constraints are in place. I agree with all above posters who have said that your first goal is to make it work. Worry about benchmarking and beautification later. With that done, I'll plan out in English a few methods for going about this -- it's easier to see what makes sense and what doesn't this way, no matter how comfortable you are with code. With that in mind, I'll start adding code, and eventually piece them together.
      (Then comes the testing, documentation wherever it needs to go, and cleanup).
      A module is a very freaking diff thing.

      Hear, hear!

      1. Make a script that "uses" your module. It doesn't matter that your modules isn't written yet, this is practice toward how you would like to use or expect your module to be used.

      2. Turn your pretend script into usable tests; make sure to include tests that will intentionally fail.

      3. After #1 and #2, then start coding on your module to actually deliver what your tests expect.

      As others have mentioned, go check out Perl Best Practices. For those less patient, the Top 10 can be found on perl.com here:

          http://www.perl.com/pub/a/2005/07/14/bestpractices.html

      cheers.
      ryanc
Re: what are all the things to be considered to write a effective perl script or module?
by ELISHEVA (Prior) on Feb 06, 2009 at 15:52 UTC
    For me, making it right and making it run are an iterative process - and this is true even though I tend to think out algorithms in code.

    If I start without planning, I'm like a car without a steering wheel. But almost always the actual writing reveals things that just aren't right with the plan - missing data or misunderstood documentation, for example. So I take a step back and reassess what data/algorithms/architecture is needed.

    I personally would recommend that you start your coding projects - whether they be script or module - with something that you can code a bit and run, code a bit and run. That way you get a reality check on your plan and your plan gets to continually take new facts and understandings into account.

    Best, beth

Re: what are all the things to be considered to write a effective perl script or module? (style)
by toolic (Chancellor) on Feb 06, 2009 at 17:24 UTC
    Good coding style and practices.

    The most important thing, as other Monks have already mentioned, is to make sure your code functions properly over a well-specified range of operating conditions. This is achieved by creating a good test suite.

    One of the next things to consider is style, which can:

    • Make your code more robust
    • Make your code easier for you to understand
    • Make your code easier for others to understand
    • Establish your reputation as a professional

    You could do worse than to read the book, Perl Best Practices.

Re: what are all the things to be considered to write a effective perl script or module?
by misterwhipple (Monk) on Feb 07, 2009 at 01:05 UTC
    Your question is wider in scope than can really be answered. For a bare beginning, however, try Perl Best Practices by Damien Conway. [Safari, Amazon]

    cat >~/.sig </dev/interesting

      If you're a fan of Twitter or RSS, individual tips from "Perl Best Practices" are also being broadcast daily.
Re: what are all the things to be considered to write a effective perl script or module?
by ww (Bishop) on Feb 07, 2009 at 14:06 UTC
    Though dHarry's and Bloodnok's replies imply something that's often said here, let me take a stab at making "step one" explicit:

    FIRST, use your native tongue to ( explain to yourself | write down ) each step you'd need to take ( "how you'd do it with pencil and paper | a calculator | manually" ) to achieve the result you want and what your $data looks like.

    and SECOND, check for modules that may already exist to satisfy your requirements.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://741828]
Approved by moritz
Front-paged by planetscape
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (6)
As of 2014-07-12 19:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    When choosing user names for websites, I prefer to use:








    Results (240 votes), past polls