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 <da...@fetter.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
