Re: Programming style: using Classes or inline

[David <dbree duo-county com>]

On Thu, Mar 16, 2006 at 09:52:20PM +1300, Grant McLean wrote:
> On Wed, 2006-03-15 at 21:13 -0600, David wrote:

[...] "use strict" and separate files.

> No, that's right, before you added 'use strict' all your variables were
> global variables.  When you declared the variables with 'my', you
> restricted their scope to the block they appeared in (eg: a subroutine)
> or to the file if they weren't in a block.

What came as a surprise to me was that I couldn't have global variables.
Again, I'm quite new to Perl and some of the rules are a bit unexpected.
However, it seems that it's _highly_ recommended to "use strict" so I
worked around this requirement by merging all the code into one file.  I
realized that I could have passed variable values or references to them
to subroutines that resided in a different file.

> Global variables are OK for quick hack scripts but as you code grows it
> can become hard to keep track of all the places which might rely on or
> alter the value of a global variable.

Yes, I'm beginning to understand this principle.  I've been following
the GTK lists for some time and have worked with GTK programming in "C".
I saw that there, using references and static variables were the chief
rule.

> > For a little perspective, my code now occupies some 1500+ lines.
>
> That would benefit from being organised into subroutines at the very
> least.

Of course I do have lots of subroutines.  As a matter of fact, I still
keep the single file arranged and marked off at the boundaries of the
original modular files.

> > if I were to adapt some of the routines to Classes, what's
> > normally best - separate files or a single file?  
>
> You can do either.  It's perfectly reasonable to declare multiple
> classes in a single file.

With the above question, I meant keeping the classes in the same file as
the mainline code.  I know that in your tutorial, you stated that while
developing your project, you kept separate files for the classes and the
mailine code, but that sometimes it was advantageous, especially after
development was complete, to merge them all into one file.

> The main benefit is organising your code into manageable chunks to make
> code maintenance easier.  I'm sure it all makes sense to you now, but if
> you come back to it after three months things might not be so clear.
> Organising things into subroutines is a good start because you have to
> give the subroutines names to describe what they do and you have to
> think about what inputs they require and what outputs they return.  By
> going a step further and making classes and methods, you can store your
> program state inside the classes rather than in global variables.
>
> Another advantage to making your code more modular,

Yes.  That was the purpose of my originally wanting to make separate
files.  But then, I was attempting to just include them as if they were
part of the main file - ala "C".  But I found that this didn't work.

> It sounds like you're in the ideal situation of being able to play
> around with the code and try different styles without being under
> pressure - and what you have already works.  So explore a bit.

Yes, I think I will.  What I need is a deeper understanding of the usage
of Classes and modules under Perl.  One other thing that was concerning
me regarding finding the files in a sensible way.  I notice your use of
FindBin (never heard of it before <g>).  I'm running Linux, and my
solution (at least while developing), is to keep them all in my user's
home and have a symbolic link to the binary in /usr/local/bin.  If I use
other files, put links to them in one of the @INC directories under
/usr/local/.

> The perlmonks.org web site is a good place for questions and quick
> feedback too.

Yes, that would be a more apropriate place.  I do realize that this
question _was_ a bit OT for this list.

> Good luck

Thanks for the wishes and especially thanks for taking the time to
reply.  You definitely have given me some insight into what I might do.