maintainable code?

[ngoc]

Hi
Now I have a perl program with 5000 lines of code in a file. I want to
divide it to many files, so that it is easy to maintain. But I face a
lot of trouble with many subroutines using class variables. I do not
want to use our. I remember 'NOT SURE' that two programs running with
two our variables with same name, it modifies each other values.

Is a 5000 lines of code in one file perl program normal in perl's world?
Or I have to change it as soon as possible if I do not want my current
and future colleagues will complain me as unexperience?

 

[John Bokma]

Hi
Now I have a perl program with 5000 lines of code in a file. I want to
divide it to many files, so that it is easy to maintain.

Can you come up with a better design?

But I face a
lot of trouble with many subroutines using class variables.

Ouch (I guess you mean global variables).

Is a 5000 lines of code in one file perl program normal in perl's world?

CGI.pm is 7500+ :-D. (But almost halve of it is documentation).

5000 lines of actual code is quite a lot to have in one program, or at
least, I can't find a script (so far) I have written that comes close to
it.

Or I have to change it as soon as possible if I do not want my current
and future colleagues will complain me as unexperience?

I think that depends much more on your coding style.

 

[Alan J. Flavell]

CGI.pm is 7500+ :-D. (But almost halve of it is documentation).

And a fair bit of that code is involved with its technique of
incremental loading. Under the covers, it's pretty modular, as far as
I can see.

I think that depends much more on your coding style.

Fair comment ;-)

 

[Tad McClellan]

I do not
want to use our. I remember 'NOT SURE' that two programs running with
two our variables with same name, it modifies each other values.

That is not true in the usual runtime environment.

 

[ngoc]

It really depends on what the program is doing. I can think of one interface
I wrote using the Tk extensions that went well beyond 5000 lines in the main
program (plus many thousands more in custom modules that accompanied it).
There was simply no way to reduce the main program any further, however,
because all the code was required for manipulating the widgets.

To the OP, hastily breaking your code up into module files to give the
appearance of good design will probably only make things worse.

Excellent advice
I can tell

you from experience that someone who asks for help (and learns from it) will
be better respected in the long run than someone who hacks code together and
then refuses to acknowledge their faults. If you have a lead or manager you
can ask advice of, take your code to them and find out what recommendations
they have. The approach can be something as simple as "I wrote this code
procedurally, but I was wondering if it should be modularized?" And then
once you have the person engaged ask how they would approach the problem of
breaking it up.

I am the only programmer in the team. I will try to ask around in the
company who know perl.

 

[Matt Garrish]

Can you come up with a better design?


Ouch (I guess you mean global variables).


CGI.pm is 7500+ :-D. (But almost halve of it is documentation).

5000 lines of actual code is quite a lot to have in one program, or at
least, I can't find a script (so far) I have written that comes close to
it.

It really depends on what the program is doing. I can think of one interface
I wrote using the Tk extensions that went well beyond 5000 lines in the main
program (plus many thousands more in custom modules that accompanied it).
There was simply no way to reduce the main program any further, however,
because all the code was required for manipulating the widgets.

To the OP, hastily breaking your code up into module files to give the
appearance of good design will probably only make things worse. I can tell
you from experience that someone who asks for help (and learns from it) will
be better respected in the long run than someone who hacks code together and
then refuses to acknowledge their faults. If you have a lead or manager you
can ask advice of, take your code to them and find out what recommendations
they have. The approach can be something as simple as "I wrote this code
procedurally, but I was wondering if it should be modularized?" And then
once you have the person engaged ask how they would approach the problem of
breaking it up.

Matt

 

[xhoster]

Hi
Now I have a perl program with 5000 lines of code in a file. I want to
divide it to many files, so that it is easy to maintain.

Why does that make it easier to maintain? I *hate* maintaining code in
which I have to keep hunting through a bunch of other files to find the
particular sub definition I need, just because someone wanted to keep their
line count under a certain number. Unless there is (or will be) some
inherent modularity, or other programs need to use the same set of code, I
wouldn't bother dividing it into several files just to meet some arbitrary
line count.

But I face a
lot of trouble with many subroutines using class variables.

Do you mean file-scoped variables? If so, then cleaning that up would
probably improve your code regardless if whether you split it up or leave
it all in one file.

I do not
want to use our. I remember 'NOT SURE' that two programs running with
two our variables with same name, it modifies each other values.

Two separate programs (running in separare perl interpretors) don't
interact with each other, unless they are specifically coded to do that.
It is more a problem of reentrance or repeatability within one program.
(Are you using mod_perl?) But you generally shouldn't use package
variables anyway. If you were going to do that, just leave it all in file
instead.

Is a 5000 lines of code in one file perl program normal in perl's world?

I can't speak for the rest of the perl world, but it is pretty unusual for
me. I don't think it has ever taken me more than 1500 lines (not counting
__DATA__ sections or the code of used of CPAN modules) to accomplish any
single task I wanted to accomplish in Perl.

Or I have to change it as soon as possible if I do not want my current
and future colleagues will complain me as unexperience?

If you colleagues are competent, you should be asking them. They probably
know far more about the specific situation (the likelihood of needing some
of those routines from other code, the level of maintenance likely to be
needed, the culter of the organization, etc.) than we do. And if they
aren't competent, then there is no telling what they will choose to
complain about.


Xho

 

[ced]

Why does that make it easier to maintain? I *hate* maintaining code in
which I have to keep hunting through a bunch of other files to find the
particular sub definition I need, just because someone wanted to keep their
line count under a certain number. Unless there is (or will be) some
inherent modularity, or other programs need to use the same set of code, I
wouldn't bother dividing it into several files just to meet some arbitrary
line count.

I hugely agree... in a similar vein, I dealt with a program whose
author parameterized everything in sight and threw it in a separate
config file.
Simple items that begged for something inline and a lexical scope were
instead hidden. Thumbing back and forth to deal with "definitions-at-a
distance" becomes the worst kind of obfuscation hell.

 

[Matt Garrish]

I am the only programmer in the team. I will try to ask around in the
company who know perl.

How you code on your own time and how you code at work can often be quite
different. You should always follow whatever style your company employs, but
if there is no explicit style and you're just looking to improve your coding
then you certainly have more leeway. Whatever the case, Object Oriented Perl
by Damian Conway is an excellent book if you're already comfortable with
Perl.

One simple step you might want to consider to improve your code is to do
away with the (ab)use of global variables. Globals do have a place, but they
can also make code a mess to read when they're used in place of good design.
See if you can't do away with the global aspect by passing values into and
returning values from your subroutines. See this recent thread as a start:

http://tinyurl.com/73wyf

And then read over perlsub as mentioned by Gunnar in it.

Matt