in reply to Re: what are all the things to be considered to write a effective perl script or module?
in thread what are all the things to be considered to write a effective perl script or module?

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! :)

  • Comment on Re^2: what are all the things to be considered to write a effective perl script or module?

Replies are listed 'Best First'.
Re^3: what are all the things to be considered to write a effective perl script or module?
by moritz (Cardinal) on Feb 06, 2009 at 16:11 UTC
    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.
Re^3: what are all the things to be considered to write a effective perl script or module?
by tilly (Archbishop) on Feb 15, 2009 at 06:21 UTC
    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.