Re: Section Dividers - What are your thoughts

I don't use this kind of comments, and when I edit a project that uses them, I find them confusing and unnecessary. Perl (and most other languages as well) already has its own way to separate code into sections: packages and subroutines. Naming them is hard, but giving them a good name means you don't need to insert the comment. You can give additional information in the documentation.

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.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Comment on Re: Section Dividers - What are your thoughts Download Code

Replies are listed 'Best First'.

Re^2: Section Dividers - What are your thoughts
by LanX (Saint) on Jun 05, 2020 at 15:29 UTC

> 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.

[reply]
[d/l]
[select]


Perl Monk, Perl Meditation
	PerlMonks