I think that a program should be composed of small pieces that are tested, flexible and pretty much atomic. Build the pieces up, prove to your own mind that they work 100%, and then assemble at the end.

Hence, I normally put all "main" code at the end of the file. Superficially, so do most people whenever they "use" something; because the subs are being declared first.

Every function should be able to stand on its own - all of its input parameters must be in @_. It's entire return should be via "return" (or updating objects passed). Therefore, the less variables unintentionally in scope, the better. Which is why we have packages and "use strict".

As a matter of course, I put a large text marker near mthe start of program logic, and explicitly call exit():

#======================================================
#    MAIN SECTION STARTS HERE
#======================================================
my ($main_vars, $so_on);

main_code;

exit(1);
[download]

If a meme (sub in this case) is required to understand another piece of code, then that meme should come before the piece of code. Sometimes I put little "silly" functions at the end of the code - stuff that is more distracting than needs to be explained.

This is called "bottom up" programming. The alternative, "top down", tends to end up with people thinking "hmm, what's the minimum I need to write to get this function to work?" IMAO^*.

see unify-dirs for an example. Note that the focus is less on where the subs end up in the file, but instead concentrates on the ordering of the memes - both in the source and the man page.

^* - In My Arrogant Opinion