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

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> 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?

I think they're easily Stroustrup's worst idea ever. You're basically
throwing away an opportunity for documentation, and that documentation
is often sorely needed. Handy example:

extern void ReorderBufferCommitChild(ReorderBuffer *, TransactionId, TransactionId,
XLogRecPtr commit_lsn, XLogRecPtr end_lsn);

Which TransactionId parameter is which? You might be tempted to guess,
if you think you remember how the function works, and that is a recipe
for bugs.

I'd view the current state of reorderbuffer.h as pretty unacceptable on
stylistic grounds no matter which position you take. Having successive
declarations randomly using named or unnamed parameters is seriously
ugly and distracting, at least to my eye. We don't need such blatant
reminders of how many cooks have stirred this broth.

regards, tom lane