develooper Front page | perl.perl5.porters | Postings from March 2023

Re: Proposal: Standardize to one space after full stops indocumentation, pod, comments, etc.

Thread Previous | Thread Next
From:
demerphq
Date:
March 18, 2023 19:50
Subject:
Re: Proposal: Standardize to one space after full stops indocumentation, pod, comments, etc.
Message ID:
CANgJU+Uwm6E8sNo-pTj9iRE-pxPvto+8bm52k7Km3nzwVyPSHw@mail.gmail.com
On Sat, 18 Mar 2023 at 20:11, Ovid <curtis.poe@gmail.com> wrote:

> On Sat, Mar 18, 2023 at 4:16 PM demerphq <demerphq@gmail.com> wrote:
>
>
>> Part of my objection to the two space rule is that I dont want to spend
>> time thinking about wrapping prose.
>>
>
> As someone who's not a core committer, I recognize that my opinion should
> not have the same weight, so please take what I say with a grain of salt,
>
> Arguments over formatting are soul-destroying. I have never found them
> productive. However, the arguments are persistent and they can be a serious
> time sink.
>
> When I put together a team to release Test::Harness 3.0, one extremely
> talented developer objected to my coding standard on the grounds that "only
> amateurs use four space indent."
>
> Because I was running that project, I put my foot down over a .perltidyrc
> file and mandated its use. I *hated* the format it produced, but because
> we found a compromise, I swallowed my pride because for me, it was more
> important that we develop than argue over formatting. It shut down the
> arguments and we were able to focus on delivering 3.0.
>

Yes. This.  As long as a tool enforces the style rule it doesn't matter
what the rule is really. I like to left hug my assignment operators because
it saves me from making stupid mistakes, especially when mixing mysql code
and perl code in the same file. If I have a tidy rule to undo that habit
then it is much better than being forced to remember that some folks will
ask me to correct any such cases before they will approve my commits.  But
that requires the file I am working has a tidy rule to start with, if it
doesn't then it almost for sure will not be consistently styled as humans
make mistakes.  So in most cases I end up manually searching for my style
leaking through. (Although it doesn't come up enough that i have written
any tools to fix it /yet/)


> Later, at the BBC, I wasn't running the project I was on, but I pushed
> hard for a similar approach. There was one holdout, a developer who also
> couldn't stand the output (in part for reasons that the entire team,
> including myself, agreed with), and he was given permission to spend some
> time augmenting Perl::Tidy with PPI to get that preferred format. I bet our
> team lead five quid that he would fail. I won that bet. That was time spent
> on fixing a personal preference rather than building value.
>
> Given what I do now, I often have the luxury of dictating a .perltidyrc
> file and a test to ensure that all code respects that. I still hate its
> output, but it works. In ten years of our consulting firm, we've only had
> one argument over formatting and the developer in question won because he
> was able to provide a .perltidyrc file that respected his choice. I just
> hit ,pt in my editor and it does the right thing.
>
> To my surprise, I've found that a few of the consultants we've worked with
> have gone on to apply this to their other clients' projects. Seems they
> prefer not arguing over formatting.
>

FWIW, I would *love* this. I basically said the same thing in my mail to
Karl. All the Perl files in our repo that use "my" style include something
like this:

# The style of this file is determined by:
#
# perltidy -w -ple -bbb -bbc -bbs -nolq -l=80 -noll -nola -nwls='=' \
#   -isbc -nolc -otr -kis -ci=4 -se -sot -sct -nsbl -pt=2 -fs  \
#   -fsb='#start-no-tidy' -fse='#end-no-tidy'

I used to have some tooling that would autodetect such a comments and then
run perltidy on the file with the rules specified.  If it were up to me
every single one of our Perl scripts  and perl files would include
something like this.  For instance Tux'es files would have his rules in
it.  Abigail files would have his, etc.  So I wouldn't have to worry about
using the wrong style when I update their code. I would just update it and
then run the tidy tool and it would get fixed. Heck, in the worst case I
could run perltidy over their files with my rules, do what I need to do,
and then run tidy with their rules and in an ideal world nobody would know
the difference.

Me? For POD, I prefer two spaces after a full stop instead of one because
> I've been using two spaces for decades. If we can find a way to automate
> this and people agree, I'd be happy. However, if we agree on one space,
> three spaces, a tab, *whatever*, I don't care. I'd go with it so long as
> we can automate it. I can write POD and let some automated tool take it
> over. Again, I know I'm not a committer, but I hope sharing my first-hand
> experience might help.
>
> So whatever is decided, I'm neutral on it, but formatting arguments are
> soul-destroying to me. The Perl community has had enough soul-destroying
> arguments. Please let's find a compromise :)
>

I agree. I don't care *what* the style is, I just want tooling to deal with
it. I only proposed the style rule I did because I could not find a tool
that knows how to sensibly wrap text like Text::Autoformat does that also
knows how to do the double space after a full stop. On the other hand,
Text::Autoformat does a great job.

I basically use this:

use Text::Autoformat qw(autoformat protect_pod);
my $in= fix_typos(do { local $/; <>});
my $out= autoformat $in, { all => 1, right=>72, protect => protect_pod };
print $out;

I have that bound to a key in vim, so I just highlight the text, hit the
key, and it's done. The fix_typos() function I dont show here just does
some basic s/// on the text to correct some common typos, such as
converting "dont" into "don't".

I am using a custom hacked version of Text::Autoformat that Damian put
together for me that understands C comments, but without that
Text::Autoformat is really nice. Except I suppose for the small issue that
it doesn't grok the two spaces after full stop rule. :-)

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous | Thread Next

nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About