Updating line length guidelines

On 08/20/2017 07:49 AM, Andres Freund wrote:

Hi,

We currently still have the guideline that code should fit into an 80
character window. But an increasing amount of the code, and code
submissions, don't adhere to that (e.g. copy.c, which triggered me to
write this email). And I mean outside of accepted "exceptions" like
error messages. And there's less need for such a relatively tight limit
these days. Perhaps we should up the guideline to 90 or 100 chars?

Considering the prominence of high resolution monitors and the fact that
we don't really review patches (outside of commentary) in email much
anymore, it seems that may even be a bit archaic. On my standard FHD
screen using a standard size font I have a line length of 210 before I wrap.

Sincerely,

JD

Greetings,

Andres Freund

--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc

PostgreSQL Centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://pgconf.us
***** Unless otherwise stated, opinions are my own. *****

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2017-08-20 09:29:39 -0700, Joshua D. Drake wrote:

On 08/20/2017 07:49 AM, Andres Freund wrote:

Hi,

We currently still have the guideline that code should fit into an 80
character window. But an increasing amount of the code, and code
submissions, don't adhere to that (e.g. copy.c, which triggered me to
write this email). And I mean outside of accepted "exceptions" like
error messages. And there's less need for such a relatively tight limit
these days. Perhaps we should up the guideline to 90 or 100 chars?

Considering the prominence of high resolution monitors and the fact that we
don't really review patches (outside of commentary) in email much anymore,
it seems that may even be a bit archaic. On my standard FHD screen using a
standard size font I have a line length of 210 before I wrap.

People commonly display multiple buffers side-by-side... But leaving
that aside, longer and longer lines actually become just hard to read
and hint that statements should be broken across lines / indentation
reduced by splitting inner blocks into their own functions.

- Andres

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 08/20/2017 09:32 AM, Andres Freund wrote:

On 2017-08-20 09:29:39 -0700, Joshua D. Drake wrote:

On 08/20/2017 07:49 AM, Andres Freund wrote:

Hi,

We currently still have the guideline that code should fit into an 80
character window. But an increasing amount of the code, and code
submissions, don't adhere to that (e.g. copy.c, which triggered me to
write this email). And I mean outside of accepted "exceptions" like
error messages. And there's less need for such a relatively tight limit
these days. Perhaps we should up the guideline to 90 or 100 chars?

Considering the prominence of high resolution monitors and the fact that we
don't really review patches (outside of commentary) in email much anymore,
it seems that may even be a bit archaic. On my standard FHD screen using a
standard size font I have a line length of 210 before I wrap.

People commonly display multiple buffers side-by-side... But leaving
that aside, longer and longer lines actually become just hard to read
and hint that statements should be broken across lines / indentation
reduced by splitting inner blocks into their own functions.

Good point. I think ~ 100 is probably a good idea.

JD

- Andres

--
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc

PostgreSQL Centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://pgconf.us
***** Unless otherwise stated, opinions are my own. *****

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Aug 20, 2017 at 10:49 AM, Andres Freund <andres@anarazel.de> wrote:

We currently still have the guideline that code should fit into an 80
character window. But an increasing amount of the code, and code
submissions, don't adhere to that (e.g. copy.c, which triggered me to
write this email). And I mean outside of accepted "exceptions" like
error messages. And there's less need for such a relatively tight limit
these days. Perhaps we should up the guideline to 90 or 100 chars?

Or maybe we should go the other way and get a little more rigorous
about enforcing that limit. I realize 80 has nothing on its side but
tradition, but I'm a traditionalist -- and I still do use 80 character
windows a lot of the time.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Aug 21, 2017 at 11:30 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Sun, Aug 20, 2017 at 10:49 AM, Andres Freund <andres@anarazel.de> wrote:

We currently still have the guideline that code should fit into an 80
character window. But an increasing amount of the code, and code
submissions, don't adhere to that (e.g. copy.c, which triggered me to
write this email). And I mean outside of accepted "exceptions" like
error messages. And there's less need for such a relatively tight limit
these days. Perhaps we should up the guideline to 90 or 100 chars?

Or maybe we should go the other way and get a little more rigorous
about enforcing that limit. I realize 80 has nothing on its side but
tradition, but I'm a traditionalist -- and I still do use 80 character
windows a lot of the time.

+1. FWIW, I find the non-truncation of some error messages a bit
annoying when reading them. And having a 80-character makes things
readable. For long URLs this enforcement makes little sense as those
strings cannot be split, but more effort could be done.
-- 
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2017-08-21 11:36:43 +0900, Michael Paquier wrote:

On Mon, Aug 21, 2017 at 11:30 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Sun, Aug 20, 2017 at 10:49 AM, Andres Freund <andres@anarazel.de> wrote:

We currently still have the guideline that code should fit into an 80
character window. But an increasing amount of the code, and code
submissions, don't adhere to that (e.g. copy.c, which triggered me to
write this email). And I mean outside of accepted "exceptions" like
error messages. And there's less need for such a relatively tight limit
these days. Perhaps we should up the guideline to 90 or 100 chars?

Or maybe we should go the other way and get a little more rigorous
about enforcing that limit. I realize 80 has nothing on its side but
tradition, but I'm a traditionalist -- and I still do use 80 character
windows a lot of the time.

Hm. Because you're used to it, or because more of them fit on the
screen?

+1. FWIW, I find the non-truncation of some error messages a bit
annoying when reading them. And having a 80-character makes things
readable. For long URLs this enforcement makes little sense as those
strings cannot be split, but more effort could be done.

I'm going to be very very strongly against splitting error
messages. Citus does split them and it makes grepping for them a
nuisance.

- Andres

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Aug 20, 2017 at 10:43 PM, Andres Freund <andres@anarazel.de> wrote:

Hm. Because you're used to it, or because more of them fit on the
screen?

Both. It's also the default window size on my MacBook.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 21 August 2017 at 10:36, Michael Paquier <michael.paquier@gmail.com>
wrote:

On Mon, Aug 21, 2017 at 11:30 AM, Robert Haas <robertmhaas@gmail.com>
wrote:

On Sun, Aug 20, 2017 at 10:49 AM, Andres Freund <andres@anarazel.de>

wrote:

We currently still have the guideline that code should fit into an 80
character window. But an increasing amount of the code, and code
submissions, don't adhere to that (e.g. copy.c, which triggered me to
write this email). And I mean outside of accepted "exceptions" like
error messages. And there's less need for such a relatively tight limit
these days. Perhaps we should up the guideline to 90 or 100 chars?

Or maybe we should go the other way and get a little more rigorous
about enforcing that limit. I realize 80 has nothing on its side but
tradition, but I'm a traditionalist -- and I still do use 80 character
windows a lot of the time.

+1. FWIW, I find the non-truncation of some error messages a bit
annoying when reading them. And having a 80-character makes things
readable. For long URLs this enforcement makes little sense as those
strings cannot be split, but more effort could be done.
<http://www.postgresql.org/mailpref/pgsql-hackers&gt;

The main argument for not wrapping error messages is grep-ableness.

Personally I'd be fine with 100 or so, but when I'm using buffers side by
side, or when I'm working in poor conditions where I've set my terminal to
"giant old people text" sizes, I remember the advantages of a width limit.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Andres Freund wrote:

We currently still have the guideline that code should fit into an 80
character window. But an increasing amount of the code, and code
submissions, don't adhere to that (e.g. copy.c, which triggered me to
write this email). And I mean outside of accepted "exceptions" like
error messages. And there's less need for such a relatively tight limit
these days. Perhaps we should up the guideline to 90 or 100 chars?

I'd rather keep the existing limit, and enforce it more strongly.

With the recent pgindent changes, it's no longer possible to save a few
chars by moving the first (or any) argument of a function to a separate
line; in some cases, we're now forced to make function arguments shorter
in order to meet the 80-char standard. In many cases that means adding
a variable declaration with a short name and a separate assignment.
That seems acceptable to me.

--
�lvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Craig, all,

* Craig Ringer (craig@2ndquadrant.com) wrote:

On 21 August 2017 at 10:36, Michael Paquier <michael.paquier@gmail.com>
wrote:

On Mon, Aug 21, 2017 at 11:30 AM, Robert Haas <robertmhaas@gmail.com>
wrote:

On Sun, Aug 20, 2017 at 10:49 AM, Andres Freund <andres@anarazel.de>

wrote:

We currently still have the guideline that code should fit into an 80
character window. But an increasing amount of the code, and code
submissions, don't adhere to that (e.g. copy.c, which triggered me to
write this email). And I mean outside of accepted "exceptions" like
error messages. And there's less need for such a relatively tight limit
these days. Perhaps we should up the guideline to 90 or 100 chars?

Or maybe we should go the other way and get a little more rigorous
about enforcing that limit. I realize 80 has nothing on its side but
tradition, but I'm a traditionalist -- and I still do use 80 character
windows a lot of the time.

+1. FWIW, I find the non-truncation of some error messages a bit
annoying when reading them. And having a 80-character makes things
readable. For long URLs this enforcement makes little sense as those
strings cannot be split, but more effort could be done.
<http://www.postgresql.org/mailpref/pgsql-hackers&gt;

The main argument for not wrapping error messages is grep-ableness.

One option for this would be to move the long error messages into one
place and have a placeholder instead that's actually in-line with the
code, allowing one to grep for the message to pull the placeholder and
then it's a pretty quick cscope to find where it's used (or another
grep, I suppose).

Personally I'd be fine with 100 or so, but when I'm using buffers side by
side, or when I'm working in poor conditions where I've set my terminal to
"giant old people text" sizes, I remember the advantages of a width limit.

I wouldn't be against 100 either really, but I don't really feel all
that strongly either way. Then again, there is the back-patching pain
which would ensue to consider..

Thanks!

Stephen

[ returning from the wilds of Kentucky... ]

Stephen Frost <sfrost@snowman.net> writes:

* Craig Ringer (craig@2ndquadrant.com) wrote:

Personally I'd be fine with 100 or so, but when I'm using buffers side by
side, or when I'm working in poor conditions where I've set my terminal to
"giant old people text" sizes, I remember the advantages of a width limit.

I wouldn't be against 100 either really, but I don't really feel all
that strongly either way. Then again, there is the back-patching pain
which would ensue to consider..

Yeah. If we changed this, we'd have to adjust pgindent's settings to
match, whereupon it would immediately reflow every unprotected comment
block. When Bruce changed the effective right margin for comment blocks
by *one* column back around 8.1, pgindent changed enough places to cause
nasty back-patching pain for years afterward. I don't even want to
think about how much worse a 20-column change would be.

(Of course, we could avoid that problem by re-indenting all the active
back branches along with master ... but I bet we'd get push-back from
people maintaining external patch sets.)

Aside from that, I'm -1 on changing the target column width for pretty
much the same reasons other people have stated. I also agree with not
breaking error message texts across lines. Having them wrap is kind of
ugly, but it's tolerable, and moving the target width by 10 or 20
wouldn't make that situation very much better anyway.

I don't feel a strong need to touch existing code just to make it fit in
80 columns, but we could try to improve that situation whenever we have
to touch a function for other reasons.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers