SPUG:Designing Programs

[Peter Darley]

Asim,
	I always start my programs with a lot of thinking about what I want the
system to do, and then get to work without too much thinking about how to
get it done.  When I do start on actual code, I take a page from XP, and
work on the feature that seems like it's the most important to do next.  I
do that small thing until it's done and then go on the next thing.  For
example, if it's a database driven application I will make a function that
loads a specific piece of data from the database.  Then I'll make another
function that does whatever processing the data requires, then another for
formatting the data, then another for outputting the data.  I test each bit
as I go, so I am always at most an hour or so away from a working system,
tho it could easily be a working system that is missing so many features
that it's not really good for anything yet.  As I have continuous releases,
this means that I can slip a bug fix or small feature into the system
without having to worry too much about the code being in a state where it
won't compile or something.
	Since I put everything together without a lot of pre-planning I often go
back and refactor my old functions.  One thing that I tend to do a lot of is
extending functions to be able to do additional things.  For example I have
a function that splits text into pieces of certain sizes.  It originally
broke only on words, but I found that I needed to break sometimes on
sentences or paragraphs, rather than words.  I had to add a switch to the
function to tell it what to break on, but needed to get the same result as
originally without changing the function calls.  In order to make this kind
of change I've started to pass all arguments to my functions in a hash.  For
example: SplitString(String=>$StringToBeSplit, Method=>'ByLength',
MaxLength=>40).  This makes it very easy to read the resulting code, since
it's always clear what the arguments to the function mean, even if you're
passing it something like $Temp, and it makes it very easy to extend the
function later by adding arguments.  I also make sure to document the
arguments of the function in case later on the name by its self isn't enough
to tell what the heck it is.
	All of my functions end up looking like this:

sub SplitString
{
	my (%Args) = @_;
	# Args: String = the string to be split
	#	MaxLength = OPTIONAL maximum length for a string segment
	#	SplitBy = OPTIONAL Word or Sentince; defaults to Word
	#	Method = OPTIONAL Half or ByLenght; defaults to Half
	Do Funcion Stuff
}

	Um, kinda rambled on there, but it's the most important thing that keeps my
code readable (at least to me) and easily extendable.

Thanks,
Peter Darley



-----Original Message-----
From: spug-list-admin at mail.pm.org [mailto:spug-list-admin at mail.pm.org]On
Behalf Of Asim Jalis
Sent: Friday, January 10, 2003 7:20 PM
To: spug-list at pm.org
Subject: SPUG:Designing Programs


I have a question. How do people design large programs with Perl?
Do you start typing code? Or do you spend some time designing it
on paper?

If you design it on paper, how do you do it? Do you define the
functions and what they will do and then flesh this out till you
have pinned down the whole program? Do you first break the
program down into modules and then flesh out each module?

Do you draw diagrams?

Or is it something completely different?

Do you use any kind of OO design ideas?

I am particularly interested in Perl and Perl design experience
and ideas.


Asim
_______________________________________________
spug-list mailing list
spug-list at mail.pm.org
http://mail.pm.org/mailman/listinfo/spug-list