Re: pgindent vs. git whitespace check

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pgindent vs. git whitespace check
Date: 2023-03-29 17:18:30
Message-ID: ZCRy5p0z+RP0oakf@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 23, 2023 at 09:36:00AM +0100, Daniel Gustafsson wrote:
> > On 23 Feb 2023, at 05:48, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > For my own taste, I really don't have any objection to // in isolation --
> > the problem with it is just that we've got megabytes of code in the other
> > style. I fear it'd look really ugly to have an intermixture of // and /*
> > comment styles.
>
> We could use the "use the style of surrounding code (comments)" approach - when
> changing an existing commented function use the style already present; when
> adding a net new function a choice can be made (unless we mandate a style). It
> will still look ugly, but it will be less bad than mixing within the same
> block.
>
> > Mass conversion of /* to // style would answer that,
> > but would also create an impossible back-patching problem.
>
> Yeah, that sounds incredibly invasive.

I am replying late here but ...

We would have to convert all supported branches, and tell all forks to
do the same (hopefully at the same time). The new standard would then
be for all single-line comments to use // instead of /* ... */.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Embrace your flaws. They make you human, rather than perfect,
which you will never be.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2023-03-29 17:34:10 Re: POC: Lock updated tuples in tuple_update() and tuple_delete()
Previous Message Jonathan S. Katz 2023-03-29 17:17:33 Re: Doc: Rework contrib appendix -- informative titles, tweaked sentences