Front page | perl.perl5.porters |
Postings from March 2023
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