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
Karl Williamson
March 17, 2023 17:57
Re: Proposal: Standardize to one space after full stops indocumentation, pod, comments, etc.
Message ID:
On 3/16/23 12:49, demerphq wrote:
> TLDR: Single space after a full stop is easier to automate, the current 
> standard taught in school, and minimally impacts reading speed. Let us 
> make the standard be one space after a full stop.

The bottom line for me personally, is if this rule were adopted, I would 
quit the project.

One reason is because of muscle memory.  I have been following the two 
spaces rule for quite a bit longer than Damian.  It would be hard for me 
to stop.

But more importantly, I would lose respect for a project that sought to 
dictate what's basically an aesthetic issue that has no bearing on the 
correct functioning of our product.  Timtoady abandoned.

It is not true that tooling is hard.  This pretty much does it:
	s/\. (*nla: )/.  /g
It enforces the two space rule.  Use of \B{sb} matching before the dot 
and a lookup hash of exceptions would improve the results.

I didn't see anyone say that the two spaces is less readable than 
single.  Rather, the arguments admit the single space has a negative 
effect but try to minimize that importance.  So why standardize on 
something that is less readable (however small you may think it is) when 
we could easily standardize on something that is more readable.

The argument that everybody else is doing it are specious.  The links I 
followed say not doing it is because of the advent of proportional 
fonts.  They are assuming a WYSIWYG editor.  But I can't imagine using 
such an editor for writing code or pod.  Those arguments simply are not 
applicable to our situation.

Bringing up "e.g.," and ".t" is also irrelevant as there is no space 
after any period there.

If you recoil at my suggestion of instead enforcing a two-space rule, 
Why?  The source is easier to read, and any documentation that gets 
formatted for output will have the formatter's rules imposed upon it. 
Proportional font output will have the spacing evened out between words 
on a line; and the current groff for fixed fonts simply strips off the 
second space.  (The original nroff did honor them.)  This means there is 
essentially no effect on users reading documentation.

As another example of tools that work: vim has done a fine job of 
wrapping comment blocks, for decades, without AI.

And I have come to believe that code should not be reformatted 
automatically at all.  I don't think it can be done well enough. 
(Expanding tabs into the appropriate number of spaces is not really 
reformatting, and is ok.)

Part of that is informed by the recent changes to embed.fnc.  The 
entries are now sorted and grouped better, which is good, but the #if's 
that I and others so carefully wrote out in such a way as to make it 
easier to follow the why and wherefore of them, are trashed.  Often, the 
most important condition has been moved from first to last.  This is a 
big step backwards, making it harder to maintain.

I write a lot of comments that use vertical alignment to clarify and 
make things easier to read.  It's just not a good idea to try to second 
guess how people have formatted their stuff.  I don't object if others 
want to follow the single space rule for their code; I just am unwilling 
to be forced to follow their aesthetic, nor have my code automatically 
formatted to follow it.

The bottom line from a project point of view is that we already are too 
intrusive in automatic formatting; it can't be done well enough, so we 
shouldn't add more.  And there really is no need to make single space 
(or double space) a standard.  Leave it up to the coder.

If you were one of those who recoiled at the idea of a two space rule. 
Again why?  I believe I demonstrated it was better than the one space 
one.  So why would you recoil?  My guess is it would be that you 
wouldn't want to have my aesthetic imposed on you, but have no problem 
imposing yours on me.  That's not perly.  But it's best to not have such 
a picayune rule at all.

Karl Williamson

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