Maintainability generally. Comprehension improves when information is in chunks that map onto an abstract model of what the process is doing. Its much easier to understand a program where dataflow only happens by argument passing and where subroutines are as minimalistic as is reasonably possible. Even when your script is pretty well unreusable its a lot easier to extend and maintain if you can ignore large chunks of the code because they are in subroutines clearly named as not being relevent to the issue at hand.

For instance lets say we have a program that scans a bunch of files and generates some stats. We could put the whole process into a single sub or not even use one, but it would be a lot easier to understand if we could just look at main and see what it does:

sub main {
   my @files=get_files(...);
   my $stats=scan_files(\@files);
   print_stats($stats);
   return 0;
}
exit(main());
[download]

I understand your point. I have myself a further problem : I write quite big applications (several -- up to 50 -- thousand lines). A typical program have hundreds of subs. Some subs are only called from other subs, which are called by other subs, .... which are called from main. How would you split that? Should I write a different package for each "big enough" sub?

That depends entirely on the circumstances and what all the subs do. If, for example, you have a group of subs that all do one thing or another with a given set of data, then it could be worth the trouble to turn said set of data into an object and treat the subs that go along with it as methods but once again, that depends entirely on the context within which one is working. I myself almost exclusively use OO style perl but that just so happens to be because the things I generally work with can easily be translated to an OO style of thinking. Could you elaborate a bit on what kind of subroutines we're talking about?

---

Remember rule one...

I have constructed my programs so that they consist of a main() sub which made up of a list of smaller subroutines.
Each line of the main() is commented.

The effect is similar to a novel with the main equivalent to a list of chapters with the sub routines making up like the contents of a book.

Also when I need to check any part of the program I can see in the main where about it is
and can quickly "find" to the sub.

Making changes updating or removing is made alot easier especially when there are no inner subroutines.


Of course not all the sub routines are listed in main() as some are within called with others

How about comprehensibility?

Subroutines as short as possible; hopefully never longer than what fits on screen. Smaller is better ( < 20-25 lines?).

With subroutines, testing becomes easier or even feasible.

(And yes, reusability: you'll end up with subs anyway, if the script will have any life beyond running once.)

reading your comment I become curious about how many lines I put on my subs and wrote this little script: counting the lines on your subs.

Running it over my code I have found that most of my subs are below 10 lines, and the most frequent size is 1 line (~18%), even when I use mcoder or Class::MethodMaker to generate common accessors that are not counted!

While my subroutines tend to be short, actual data on benefits of short subroutines is more ambiguous. In fact there is some data saying that short subroutines are counterproductive. Obviously this doesn't match widely held current beliefs. See Short routines matter more in OO? for some guesses as to why this might be.

So yes, subroutines greatly aid reusability, on both levels.

Additionally, subs are easier to test than a top-down script. You only have to extensively test one sub at a time - once it's clean, you're confident to use it. Writin unit test is also simpler for subroutines with well defined interfaces than for whole scripts.

On a top to botton script high level and low level ideas get "mixed" and even if it is commented, you have to read it fully to understand what it does.

Discovering which data is input and output for a particular step can also be a hard task because variables can be referenced in any place. On the other hand, when using subroutines, seen what is input and output in every step is trivial, you only have to look at the glue code between the subroutine calls.

Other problem that sometimes appear, is naming temporary vars, specially because we always try to use common names like $len, $i, $j. You have to take care to use different ones on every step or to ensure that you can reuse them without trouble or to open new scopes. When using subroutines this problem just go away.

"Code Complete 2" has an entire chapter (#7) on subroutines. Why to make them. How to design them, name them. How long they should be. What parameters they should take. I would highly suggest reading that, even if its just pulling it off the shelf at your local Super Mega Book Store.

But the way I've always thought about subroutines is NOT in terms of reuse. Equating subroutines with reuse is the great downfall of many a new programmer. When you write out your code you often have no idea what is or is not going to be reused. No, subroutines are for something far more important: encapsulation. Limiting what you have to know and how wide an effect a change can have.

In much the same way as a book is broken down into chapters, sections and paragraphs, your code should be broken down into modules, libraries and routines. Why? Because trying to understand a bunch of information smashed together sucks. Subroutines, like paragraphs, let you know where one idea begins and ends. They allow you to skip around within the code. When well named, they allow you to know what the routine does without having to read all the details allowing you to skim.

Routines provide a beginning and an end of scope. Scope for variables. This limits just how much information you need to keep in your head at once. To understand a routine you need to keep in mind A) the variables passed in B) the variables local to the routine C) the (hopefully very few) globals used. When reading a blob of code you have to keep in mind nearly all possible variables because any one could be used at any moment. Since there is no structure any given line of code could manipulate any given piece of data.

Routines also make testing and documentation much, much easier. Its easy to document something that does one thing rather than something that does a dozen. Its also much easier to test. Once you've got a solid foundation of tested routines figuring out what went wrong when you combine them becomes easier. You know the routine works, it must be something about the integration code. Again, limiting the scope of what you need to worry about.

And finally to reuse. Its difficult to know up front what i s and is not going to be reused. Reuse is something which is discovered. When your code is written in one big blob its difficult to see what parts can be made into reusable widgets. Its also a lot of work to extract the reusable bits, especially after they've been hacked on, so you're less likely to redesign a hunk of code into a reusable routine than to just cut & paste. When you write out each logical chunk as a routine as you go the pieces are evident and there for the taking. The borders are well defined so you will be less likely to tangle them up in the course of maintaining the code. The code will then actually get reused.

I had a thread on cross-platform editors a while back. I always like Emacs, but had gotten away from it because of it's lack of code-folding (which is what you're talking about). However, a respondant to my query replied with information about an Emacs LISP file that adds code-folding. I'm using Eclipse now, so I haven't run the ELISP referenced, but it is here: Re: Cross-platform development: editors

Yoda would agree with Perl design: there is no try{}

I just looked at the folding.el mentioned in that other thread and it mentioned that imenu (included with Emacs) and hideshow might be good packages for function/block-level hiding. The former is interesting, and I didn't know about it, but it doesn't provide hiding capability. I just tried out the latter and it seems good so far at hiding blocks.

I just added a response to the mentioned node. (Re: Cross-platform development: editors) It's a bit involved, but I got outline-minor-mode working per advice from emacswiki.org