Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

(Ovid - Yes, but) Re(?): What you want and perl advocacy gone way wrong

by Ovid (Cardinal)
on Jan 18, 2001 at 02:36 UTC ( #52632=note: print w/replies, xml ) Need Help??

in reply to Re (tilly) 3: What you want and perl advocacy gone way wrong
in thread module info

tilly, while I agree in theory with what you are saying, I have a problem with this.

Let's say I have a program that reads an initialization file, opens a data file, does some processing, summarizing, error reporting, etc. A simple outline of the program might run like this (sorry for the formatting):

|--initialization--|--read .ini file | |--set globals | |--open files | main-|--process ledger--|--while not eof | | | | read next line |--addToProcessA | | | | | determine type--|--discard | | | | | write to file |--error reporting | |--termination-----|-- summarize results | write summary to file | close file
If that's the case, it's relatively simple to document and follow the process flow. But, even for a simple process like this, here's what I usually find in production programs:
read .ini file set globals open files while not eof read next line determine type addToProcessA -or- discard -or- error reporting end while write results summarize write summary to file close file
It's a fairly linear run-through from top to bottom. There is little if any attempt to modularize the code. When that gets significantly larger, documentation becomes critical. I'm not disagreeing with how one should write the programs (small functions are the way to go), but many, if not most of the programmers that I have met simply don't appreciate this.

As a side note, I find that even those who do appreciate this will often do the straight run-through rather than the modularization. I sometimes have that in my code (usually a sign that I've been given rotten specs).

As a second side note, I just hacked together the example. There's no serious attempt to make the names more sensible or to really break it down properly. I'll call it pseudo-Warnier-Orr :-)


Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Replies are listed 'Best First'.
Re (tilly) (?): What you want and perl advocacy gone way wrong
by tilly (Archbishop) on Jan 18, 2001 at 03:57 UTC
    I am not sure what your objection is. You are saying that most people don't do a good job? True but IMHO irrelevant. As the saying goes, there is no real difference between Perl scripting and Perl programming, but the ones who think of it as programming generally do a better job.

    As you note, scripting the problem straight through makes it harder to understand later than programming it properly. As you mention, people often script and then try to solve their problems with volumes of documentation. At which point you have two problems instead of one.

    Documentation is both good and necessary. It tells people what they can and cannot expect, it tells people what interfaces should be used and how to use them, it provides a spec by which the programmer figure out what the code should be doing, it provides something for testers to test and it helps users.

    It does not replace the need to program well.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (1)
As of 2022-01-27 23:57 GMT
Find Nodes?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:

    Results (72 votes). Check out past polls.