Moreover, I'm a huge fan of Skimmable code (slides here). Sacrificing three lines of code to a section divider means I need to scroll more, so it's harder for me to keep track of the context when debugging.

I'm not against comments in general. I use them when I feel the code is tricky or needs justification. But I don't want to copy'n'paste a template every time I want to comment, I just start with a single #. Are you sure all the collaborators will use the same number of octothorpes?

I tend to put an empty line after any expression that can change the flow (i.e. after anything containing return, next, etc.). I often use "paragraphs" inside subroutines, i.e. I insert empty lines inside subroutine bodies to separate groups of lines that are tightly related. In larger projects, I sometimes decided to separate subroutines with two empty lines instead of one so the distinction between subroutines and paragraphs is more visible.

As you can see, all this is subjective. I'm not even able to follow my own preferred style in my personal projects. At work, I just clench my teeth :-)

Update: added the link to the slides.

> Moreover, I'm a huge fan of Skimmable code

unfortunately is this link only showing the talk abstract, but no further details.

From what you describe, this is very close to the recommendations of Damian's PBP, especially:

> I often use "paragraphs" inside subroutines

IIRC, this is called "chunks" there, though I tend to start them with one full line comment

You didn't mention it explicitly, but avoiding too many nesting levels is one of general best practices.

They are a clear indication for more smaller subroutines.

for instance a contrived example following the input/process/output scheme

#--- calculate debts per client
my %result;
for my $client (@clients) {
    
    #--- get data
    my %details = fetch_details_from_DB($client);
    ...
    ...
    ...

    #--- process data
    my $debt = calculate_debts(%details);
    ...
    ...
    ...

    #--- store result
    $result{$client} = $debt; 
    ...
    ...
    ...

}
[download]

I like to read such a loop inside a full page ( at most 100 lines), even prefer to have a sub inside such a window. (I hate guessing in which function/loop I'm currently being, {update: I want to see the declared private variables too})

So if the chunks consist of more than a handful of lines, I try to refactor them into a bunch of dedicated subs.

With meaningful "self-documenting" naming I can even avoid the then redundant #--- documentation line.

Hope I'm grasping your idea, and would love to hear where Schwern's recommendations are differing from Damian's.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

UPDATE

for very strange reasons I'm getting my own code displayed with doubled line distance. I hope it's only me, logging out shows them correctly.

update

Changed the css settings to line-height: 10px , no idea when this changed.

There may be some switch in Perltidy so that it doesn't do the indent in the middle, I haven't found an answer yet.

The documentation says:

       -isbc,  --indent-spaced-block-comments
           If there is no leading space on the line, then the comment will not
           be indented, and otherwise it may be.

And thus we see:

$ cat 11117714.pl 
sub foo {
    my $i = shift;
####################
# Name or Description of Code Section
####################
    return ++$i;
}
$ perltidy -npro -isbc < 11117714.pl 
sub foo {
    my $i = shift;
####################
# Name or Description of Code Section
####################
    return ++$i;
}
$
[download]

I usually find something like this is eye-catching enough:

code code code code;

#
# Bleh bleh bleh bleh
#

code code code code;
[download]

> but using POD for this is better than what you have

The debugger perl5db.pl is a good counterexample to this thesis.

It has a big command loop where the users input is read and the documentation for each command is interspersed for each command section.

The documentation will show up in the same order like programmed and must stay at this chronological position.

This makes refactoring the code extremely difficult. Frankly it's a PITA.

I'm a fan of interspersed function docs with POD, but

• only use it for external documentation.
• don't make code position dependend on it
• remember subs can be moved, linear code normally can't

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

The documentation will show up in the same order like programmed and must stay at this chronological position.

This might make a case for literal programming (write code and documentation in the order one would want to read it, but reorder the code chunks in the order it should run in), but that comes with its own bag of problems and requires trade-offs that one might consider unacceptable.

Hi

Its like asking "which smells more?"

They both smell, they dont belong