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

Peter Geoghegan <pg@bowt.ie>

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-17T00:15:24Z
Lists: pgsql-hackers
On Fri, Sep 16, 2022 at 4:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Agreed; I see no need to tolerate any inconsistency.

The check that I used to write the patches doesn't treat unnamed
parameters in a function declaration as an inconsistency, even when
"strict" is used. Another nearby check *could* be used to catch
unnamed parameters [1] if that was deemed useful, though. How do you
feel about unnamed parameters?

Many of the function declarations from reorderbuffer.h will be
affected if we decide that we don't want to allow unnamed parameters
-- it's quite noticeable there. I myself lean towards not allowing
unnamed parameters. (Though perhaps I should reserve judgement until
after I've measured just how prevalent unnamed parameters are.)

> Yeah.  I'd be inclined to handle it about like cpluspluscheck:
> provide a script that people can run from time to time, but
> don't insist that it's a commit-blocker.

My thoughts exactly.

[1] https://releases.llvm.org/14.0.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-named-parameter.html
-- 
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.