Re: How to write long programms?

[mothra]

well i'm working on a cgi programm, and i've noticed it's starting to be pretty long (250)...

250 lines...long...? Wow. :) I yearn for the project I get to maintain that is any LESS than 10,000 - 15,000 lines (which I would still call a fairly small program, certainly not a "large" one :).

But anyways, for me, I find that the OO paradigm is a nice way to manage complexity. Taking the time to think about pieces of functionality as "objects" within a "system" (notice the Dr. Evilish quotations there) is the most natural way for me to manage complexity, and can lead to some very elegant solutions (not that functional programming can't, of course). There's no magic answer though, because everyone does things in their own way, and programming is hard. Think about what you're doing, seeing how you can break up your source files into logical units (aka, modules).

• Ideally, you'll want to follow what tilly would recommend and keep your functions to <= 50 lines. In practice, it's almost impossible to always stay under this benchmark all of the time, but it will remind you to NEVER fear making your code modular. ie. Even in your 250 line program, your code may be such that it might require 15 functions to keep the cohesion high, and the coupling low.
• Never hard code magic numbers, or you'll experience magical side-effects as your system grows.
• Constantly refactor.
• Avoid global variables because again you'll experience side-effects as your system grows.
• Don't overcomment. Too much commenting will get in the way of what could otherwise have been a nice, compact piece of code.
• If you're really concerned in terms of "how do I organize my files?" when working on larger systems, use an IDE or text editor that supports "projects".

Needless to say, this is a question that is hard to answer, because again, everybody does things in their own way. The more code you write, and the more time you spend thinking about the way the pieces of your system are working together (or aren't), the sooner you'll figure out what works for you.

[ybiC]

Your fourth suggestion (Avoid global variables) struck a chord for me, mothra, as I've recently received that same advice for improving the quality of my own modest Perl scripts.

What negative side effects result from using global variables in large programs?
    cheers,
    Don
    bumbling toward Perl Adept
    (it's pronounced "why-bick")