«

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?

ngoc <> wrote:

> 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+ . (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.

--
John Small Perl scripts: http://johnbokma.com/perl/
Perl programmer available: http://castleamber.com/
Happy Customers: http://castleamber.com/testimonials.html

On Mon, 5 Sep 2005, John Bokma wrote:

> CGI.pm is 7500+ . (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.

> > 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.

Fair comment

ngoc <> wrote:

> 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.


--
Tad McClellan SGML consulting
Perl programming
Fort Worth, Texas

>
> 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.

"John Bokma" <> wrote in message
news:Xns96C832EF6547Ccastleamber@130.133.1.4...
> ngoc <> wrote:
>
>> 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+ . (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

ngoc <> wrote:
> 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

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB

wrote:

> > 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.
>

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.

--
Charles DeRykus

"ngoc" <> wrote in message
news:431c62b0$...
>
>> 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.
>

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