rah has asked for the wisdom of the Perl Monks concerning the following question:
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
Re: Style Question: small and modular, or big enough to do the job in one piece?
by derby (Abbot) on Feb 14, 2002 at 13:52 UTC
|
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 | [reply] |
|
++ 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.
| [reply] |
|
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.
| [reply] |
Modularize - Re: Style Question: small and modular, or big enough to do the job in one piece?
by metadoktor (Hermit) on Feb 14, 2002 at 05:13 UTC
|
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." | [reply] |
Re: Style Question: small and modular, or big enough to do the job in one piece?
by seattlejohn (Deacon) on Feb 14, 2002 at 07:30 UTC
|
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? | [reply] |
Re: Style Question: small and modular, or big enough to do the job in one piece?
by Ryszard (Priest) on Feb 14, 2002 at 06:33 UTC
|
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.. :-) | [reply] [d/l] |
Re: Style Question: small and modular, or big enough to do the job in one piece?
by abaxaba (Hermit) on Feb 14, 2002 at 08:04 UTC
|
$response=200>6*30?"6 programs":"1 program";
print "$response\n";
#Of course, there are maintenance issues :) | [reply] |
Re: Style Question: small and modular, or big enough to do the job in one piece?
by dragonchild (Archbishop) on Feb 14, 2002 at 13:43 UTC
|
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. | [reply] |
|
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.
| [reply] |
Re: Style Question: small and modular, or big enough to do the job in one piece?
by Anonymous Monk on Feb 14, 2002 at 05:09 UTC
|
Other things being equal, 180 lines may be preferable to 200 lines | [reply] |
|
|