[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cgiapp] Length of Application Modules...


> module is 1804 lines long, with a file size of 67K.  It contains 26
> runmodes. 

Ye gods man!  How do you maintain such a beast?  My largest apps are
600-800 lines, coutning POD, and they are the limit of maintainability.
For me, at least.  Anything larger and I tend to dread maintenance,
since it takes me so long to figure out what is happening where.  (Of
course, I maintain many different apps)

> modules to handle classes of users instead of one massive module, but
> I think I would be repeating a lot of code with that approach.

In practice, everytime I break an app down into smaller parts, I find I
end up repeating code LESS.  (Usually because your code might have 50
ways of doing similar tasks, and you can turn it into one module with an
argument or two).  

> Thoughts?  I'd like to continue to improve my technique as I'm sure
> I'll be writing more with CGI::App.

I'm hardly the all knowing Perl God, but my experince with CGI::App over
the last two years or so (wow, is it really that long?) has been that
breaking it up makes maintenance easier, which makes EVERYTHING easier.  

I have a few different ways of making a large app smaller:  

1) Push as much functionality as I can in to non-CGI::App helper
modules.  This often has the side effect of letting me reuse the code
for non-web-based scripts and in other apps.  Plus, the thinking
involves often makes new tasks easier.  For example, our site has a
database that holds page linking relations in it.  We have several
modules that tinker with said db.  Abstracting that tinkering into
modules makes all the apps smaller, and easier to maintain.  With a
few extra tuits, I intend to make a module to be tied to a hash that
will make the code even easier to use.

2) Subclass.  If I have a case where there is a lot of shared
functionality, and then a lot of different functionality,. I'll create a
base class that holds the shared functionality, and subclasses that hold
the specifics.  If needed, I'll subclass subclasses.  It makes the
project as a whole a bit bigger, but each app is smaller, there is
excellent code reuse, and maintainability is wonderful.

One area in which I differ from the "norm" on the list is that I feel
quite free to have many instance scripts for one module.  I don't,
however, use it to separate user classes (usually).  Instead I use it
with app modules that are generic tools (file upload/download, forms 2
email, surveys, etc).  

One suggestion I have is to look over the linux kernel coding
recommendations.  (I found them in Linux Journal, I'm sure they're
around in many places).  While a lot of it isn't relevant, there are
some beauties.  My favorite is the part saying each fucntion
(subroutine) should only be 10-15 lines long.  anything more can be
broken down.  I flagrantly break this rule, but keeping it mind
encourages trim clean subroutines, which end up being self-documenting
and helsp to show which chunks of code can and should be moved off to a
non-CGI::app module.

-- 
SwiftOne
suppressed

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed


Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.