Horton

Re: Making C function declaration parameter names consistent with corresponding definition names

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-09-16T23:36:50Z
Lists: pgsql-hackers 
On Fri, Sep 16, 2022 at 4:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I agree, this has always been a pet peeve of mine as well.  I would
> have guessed there were fewer examples than you found, because I've
> generally fixed any such cases I happened to notice.

If you actually go through them all one by one you'll see that the
vast majority of individual cases involve an inconsistency that
follows some kind of recognizable pattern. For example, a Relation
parameter might be spelled "relation" in one place and "rel" in
another. I find these more common cases much less noticeable --
perhaps that's why there are more than you thought there'd be?

It's possible to configure the clang-tidy tooling to tolerate various
inconsistencies, below some kind of threshold -- it is totally
customizable. But I think that a strict, simple rule is the way to go
here. (Though without creating busy work for committers that don't
want to use clang-tidy all the time.)
-- 
Peter Geoghegan

Commits

  1. Harmonize parameter names in pg_dump/pg_dumpall.

  2. Harmonize parameter names in contrib code.

  3. Harmonize more lexer function parameter names.

  4. Harmonize parameter names in ecpg code.

  5. Harmonize lexer adjacent function parameter names.

  6. Harmonize more parameter names in bulk.

  7. Harmonize parameter names in storage and AM code.

  8. Harmonize heapam and tableam parameter names.

  9. Consistently use named parameters in timezone code.

  10. Consistently use named parameters in regex code.

  11. Harmonize reorderbuffer parameter names.

  12. Make check_usermap() parameter names consistent.