Re: [HACKERS] Updating line length guidelines - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Updating line length guidelines
Date
Msg-id 20170822132841.GL4628@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Updating line length guidelines  (Craig Ringer <craig@2ndquadrant.com>)
List 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>
>
> 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

pgsql-hackers by date:

Previous
From: Sokolov Yura
Date:
Subject: Re: [HACKERS] Lazy hash table for XidInMVCCSnapshot (helps Zipfiana bit)
Next
From: Ashutosh Sharma
Date:
Subject: Re: [HACKERS] Page Scan Mode in Hash Index