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
March 18, 2023 19:29
Re: Proposal: Standardize to one space after full stops indocumentation, pod, comments, etc.
Message ID:
On Sat, 18 Mar 2023 at 19:31, Christian Walde <>

> On Thu, 16 Mar 2023 19:49:27 +0100, demerphq <> wrote:
> > I wrote some code some time back which was intended to auto format all of
> > our documentation, side-bar comments, and etc, so that they respected our
> > "80 column preference".
> >
> > So I would like to propose that we standardize our text to use one space
> > after a full stop, and make it "ok" to reformat any text that uses two
> > spaces after a full stop to have only one. Such matters should be left up
> > to rendering tools, and we should not impose tedious manual work on our
> > devs.
> While well meant, the solution here shoots past the /achieve.
> Some experience from my time in the field indicates the best solution here
> is to apply a lenient measurement and test that complains when a test suite
> is run, and leaves it to the author whether to ignore it or apply changes.

> In my particular case this stems from having a perl critic script that
> complains about policies, but only considers the changes of the past few
> commits, skipping files that have not been changed substantially. Even
> myself will often ignore it on account of time constraints, but on the
> whole it helps without being a hindrance.

Interesting notion, but we don't want people merging patches that fail

My intent and desire is to produce and use tooling that ensures our files
are formatted in some consistent manner. Once those tools exist I dont have
to worry about my own personal style, I just have to ensure I run the
tools. IOW, I dont want to have to think about it. I want tools to think
about it.

As I said in my TLDR, I want to free people from thinking about style
because there is tooling in place that ensures that the style is consistent
and meets "regulations" and that if they use the tooling all will be well.
I dont want tests that nag me when I fail to comply, especially if there
isn't tooling to make sure my code complies with the rules, that is just
torture to me. Assuming there is tooling that makes sure my code is
compliant with the rules I'd rather prefer that it gets executed
automatically so I dont have to think about it than getting nagged about it.

I generally think computers and software should free me from having to do
tedious tasks, and they should not be the source of new tedious tasks.
Sometimes this means adjusting my own expectations and adopting rules that
make it easier for the tooling to know what is going on so that they can do
the job.

Just think about how the vast majority programming languages are
structured. They aren't structured in the ways humans who speak language X
would expect, they are structured so that you can produce an LR grammar and
have it compile correctly without grammar conflicts (IOW so you can use
Bison or something equivalent to convert the grammar into a program). They
are structured so that the compiler has an easier time, not so that the
user has an easier time.  There are many practices that are conventional in
programming because it means the tooling we use can be simpler and more
effective. There is a good reason for this: humans are easier to teach than
programs, and natural languages are not very consistent despite what
their speakers think. (I remember from University that studies on
grammatical consistency of English speakers showed that the better educated
you were the less consistent your grammar was.) The few programming
languages that tried to go against this type of reasoning were disasters.
(COBOL anyone?)

Anyway, I am fine to let this thread die. Karl has stated he will walk away
if we adopt the rule I proposed. I dont want Karl to walk away, so I
withdraw the proposal that we adopt this rule. Should someone give me a
tool that enforces Karls style I will happily use it, until then I will
continue to use Text::Autoformat instead. Other than this issue with full
stops it does a *great* job and I use it to format my commit messages, my
pod updates and my C and perl comment updates. Ever since I adopted it I
stopped getting nagged by our tests for POD line lengths, and I stopped
spending time thinking about text wrapping and layout. I just highlight and
then hit the key binding I set up in my editor.  That is how things
*should* be IMO.


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

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About