From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | David Fetter <david(at)fetter(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Copypasta in the PostgreSQL source |
Date: | 2018-12-17 23:41:23 |
Message-ID: | 20181217234123.fe3odv3rg7hsoojv@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-12-18 00:36:55 +0100, David Fetter wrote:
> On Mon, Dec 17, 2018 at 05:31:22PM -0500, Tom Lane wrote:
> > David Fetter <david(at)fetter(dot)org> writes:
> > > Please find attached a run of a tool that looks for duplicated
> > > tokens. I've removed some things that seem like false positives,
> > > basically all from the stemmer part of the source, but there's
> > > still a lot.
> >
> > I thought you were talking about problems like "that that" typos,
> > but on looking at the file, what this is actually complaining about
> > is any duplicated code segments anywhere. I do not find this
> > helpful. Refactoring to the point that dozen-line code stanzas
> > never appear more than once would be incredibly invasive, likely
> > very bad for performance, and I don't think it'd improve readability
> > either.
>
> Is there a threshold, possibly much larger than a dozen lines, where
> such refactoring would actually make sense?
Sure, sometimes. But it seems unlikely that a report based on the
technology at hand here would be useful. If none of the code has changed
in recent times, it's not that usually worthy of a lot of attention to
adapt, unless we're talking much larger pieces of code. And a fair bit
of what's pointed out in that report is well known (e.g. that ecpg
duplicates a lot of code in a horrible manner). I think to be useful
it'd need to actually point out very similar code, that's starting to
diverge further - but that's obviously a much harder thing to achieve.
> > > - Would it make sense to make some kind of git commit trigger that
> > > at least warns when a new one has been introduced?
> >
> > Commit triggers are NOT the place for heuristics about code quality,
> > even if they're well-considered heuristics.
>
> Where's a better place for such heuristics? I'd like to think that
> there are opportunities for more automation than we currently have, on
> that score. Maybe a `make` target?
If we find useful targets, we can integrate them that way. I don't
consider this to be a worthy case though.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-12-17 23:43:53 | Re: explain plans with information about (modified) gucs |
Previous Message | Tomas Vondra | 2018-12-17 23:38:16 | Re: explain plans with information about (modified) gucs |