Re: Updating line length guidelines

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Updating line length guidelines
Date: 2017-08-22 13:28:41
Message-ID: 20170822132841.GL4628@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Craig, all,

* Craig Ringer (craig(at)2ndquadrant(dot)com) wrote:
> On 21 August 2017 at 10:36, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
> wrote:
> > On Mon, Aug 21, 2017 at 11:30 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
> > wrote:
> > > On Sun, Aug 20, 2017 at 10:49 AM, Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2017-08-22 13:54:55 Re: Page Scan Mode in Hash Index
Previous Message Sokolov Yura 2017-08-22 12:17:40 Re: Lazy hash table for XidInMVCCSnapshot (helps Zipfian a bit)