Style Question: small and modular, or big enough to do the job in one piece?

[rah]

I was curious about different people's approach to this. I write fairly simple scripts (I am a simple sysadmin).
My longest script is about 300 lines, 100 of which is perldoc. That one, was a <qoute>generic</quote> FTP script that I had hoped would
do all of the sorts of ftp things we do (get, put, mget, mput, rename, etc), in one script driven by a control file.
Of course every time we came up with a new ftp batch job, it brought along slightly new requirements, so this script grew
and grew to its present size. I have been chided by one of our architects for not breaking it up into smaller pieces and using
them in concert.

What are the feelings here? Theses pieces are not large enough or general enough to be thought of as OO,
so that's not what I'm asking. More like, if you could write one 200 line script that worked for 12 different batch jobs,
or 6 smaller scripts (say 30 lines) to do the same, which approach would you take?

Thanks,
Rich

[derby]

rah,

It really depends. Asking if 200 lines is too much is kinda like asking is 200 coins too much. It all depends. Do you have 200 pennies, 200 quarters or 200 gold pieces, or a nice mixture? 200 lines means really nothing. When you're looking at those two hundred lines, ask yourself these questions:

How many of them are exact copies?
How many of them are similar copies?


What you want to do here is figure out how much "copy-n-paste" re-use you have - those are prime canidates for refactoring into subroutines.

Once you have the "copy-n-paste" out of the way. Take a look at what's left and ask your self these questions about each subroutine in term (and don't forget the implicit main subroutine).

Is this beastie cohesive - does it do one thing very well or is it all over the place
Is this beastie coupled - does it depend on global data or does it poke at other subroutine's data.

Shoot for high cohesiveness and low coupling (the holy grail of programming). The great thing about looking at cohesiveness and coupling at the functional level is that it can really help you refactor code into an OO level - hmmm this set of five methods work on this one data structure while this set of 3 work on another - eureka ... module discovery.

Now once you've done all that, your 200 lines of code may now be 300 lines of code - is that any worse? Well from a run-time perspective - probably. Calling subroutines or loading modules and calling methods cost you. But that cost is hopefully down in the noise and what you really gain is ease of maintainence and ease of extending when new batch jobs come along.

-derby

[dragonchild]

++ Brother derby! This is exactly the kind of analysis that needs to be done.

The most important thing in the vast majority of coding projects is maintainability, or "How easily can someone who's never seen this code before go in and make a change with a reasonable certainty that nothing else was adversely affected?" The answer to that question determines the code's maintainability.

Run-time analysis is, in my mind, overused. 99.999% of all coding projects do not have a run-time constraint. Yeah, we all want our code to finish NOW, but if it takes 2 seconds instead of 1.8 seconds, that's ok. If adding .2 seconds to its runtime allows a programmer to safely make a change in 5 minutes instead of 2 hours, that's worth it.

Memory constraints should be treated the same way. Most machines are much more powerful hardware-wise than can be used by a reasonable user. Do the right thing for yourself. It's only a machine.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[Anonymous Monk]

Maintainability is exactly the issue here. My architect freind says break it up so each piece is small and easily digestible w.r.t. function, even if this means calling multiple scripts to do the "job". My view is to have it all in one place so I don't have to chase around multiple files/locations to figure out what the job is doing.

I don't think the two are completely at odds. Even though my script ended up longer than I expected, I did:
- use subroutines to avoid repeating the same constructs
- commented liberally, since I and my admins are all relatively new to perl
- wrote a pretty comprehensive perldoc, that describes what the control file looks like and how to call the script with the control file and the available args.

[metadoktor]

As a computer science prof once said to our class...keep your subroutines (at most) at about the size of a page of code. It does make life easier especially when you go back and read that code that you wrote a few months ago. A subroutine or function that says 'ftp's using get' or whatever is far more intuitive than fifty lines of code in the middle of two-hundred that does the same thing.

Update:

This being Perl, a msg from lachoy reminded me that I should probably change this to subroutines (instead of the original modules) since module means something different (i.e. a collection of subroutines) in Perl.

metadoktor

"The doktor is in."

[seattlejohn]

I admit, 200 lines of code (excluding the perldoc) doesn't seem like a particularly large amount to me, unless it is a mass of spaghetti code with no real structure to it. When you say the architect is chiding you for not breaking it up, do you think he literally means breaking up into separate scripts, or simply doing a better job of factoring out common functionality into reasonable subroutines and otherwise cleaning up the code?

[Ryszard]

One method I have used in the past (non OO) is writing all the 'generic' sub routines, and sticking them into a library file, which you then "require".

Once you have coded your subbies in a generic manner, you do all the logic in the main app(s) and call your subbies.

I like to use hashes as the parameters also, eg:

my $retval=&ftp_put_batch(batchname => 'batch001', host=>prod01);

So I guess to answer your question, parameterise, and break it back down to generic functions would be my preferred option. From there you'll have a nice shiny new set of building blocks.. :-)

[abaxaba]

$response=200>6*30?"6 programs":"1 program";
print "$response\n";

#Of course, there are maintenance issues :)

[dragonchild]

Theses pieces are not large enough or general enough to be thought of as OO,

Why not? Would it make sense to make them so? Note that I consider the use of Exporter to be somewhat OO, as it's working with encapsulation and reusability. (2 out of 3 ain't bad, or so the song goes...)

Of course, I'm wondering why you're not using Net::FTP ...

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[Anonymous Monk]

I am. Net::FTP is doing all the hard work. My code is really just making it a specific job, passing in who to connect to, what files to do what with, and allowing me to store encrypted login and passwords in the control file.

[Anonymous Monk]

Other things being equal, 180 lines may be preferable to 200 lines