Thread: [HACKERS] Updating line length guidelines
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? Greetings, Andres Freund
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. *****
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
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. *****
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
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
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
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
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.
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.
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
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> > > 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