maintainable code?

Discussion in 'Perl Misc' started by ngoc, Sep 5, 2005.

  1. ngoc

    ngoc Guest

    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, Sep 5, 2005
    #1
    1. Advertising

  2. ngoc

    John Bokma Guest

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

    --
    John Small Perl scripts: http://johnbokma.com/perl/
    Perl programmer available: http://castleamber.com/
    Happy Customers: http://castleamber.com/testimonials.html
    John Bokma, Sep 5, 2005
    #2
    1. Advertising

  3. On Mon, 5 Sep 2005, John Bokma wrote:

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

    > > 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 ;-)
    Alan J. Flavell, Sep 5, 2005
    #3
  4. 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
    Tad McClellan, Sep 5, 2005
    #4
  5. ngoc

    ngoc Guest


    >
    > 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.
    ngoc, Sep 5, 2005
    #5
  6. ngoc

    Matt Garrish Guest

    "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+ :-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
    Matt Garrish, Sep 5, 2005
    #6
  7. ngoc

    Guest

    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
    , Sep 5, 2005
    #7
  8. ngoc

    Guest

    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
    , Sep 5, 2005
    #8
  9. ngoc

    Matt Garrish Guest

    "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
    Matt Garrish, Sep 6, 2005
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?Q2FybG8gTWFyY2hlc29uaQ==?=

    Fire Code behind code AND Javascript code associated to a Button Click Event

    =?Utf-8?B?Q2FybG8gTWFyY2hlc29uaQ==?=, Feb 10, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    21,225
    =?Utf-8?B?Q2FybG8gTWFyY2hlc29uaQ==?=
    Feb 11, 2004
  2. Replies:
    22
    Views:
    1,401
    Miselaineous
    Sep 24, 2006
  3. John Salerno
    Replies:
    9
    Views:
    403
    Thomas Nelson
    Apr 9, 2006
  4. Michael Yanowitz
    Replies:
    4
    Views:
    377
    Christos Georgiou
    Apr 10, 2006
  5. Bil Kleb
    Replies:
    1
    Views:
    97
    gabriele renzi
    Apr 5, 2006
Loading...

Share This Page