Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oZMVz-0006CN-M6 for pgsql-hackers@arkaria.postgresql.org; Sat, 17 Sep 2022 01:21:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oZMVy-0003j7-8X for pgsql-hackers@arkaria.postgresql.org; Sat, 17 Sep 2022 01:21:02 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oZMVx-0003iy-Vd for pgsql-hackers@lists.postgresql.org; Sat, 17 Sep 2022 01:21:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oZMVv-0007nG-MG for pgsql-hackers@lists.postgresql.org; Sat, 17 Sep 2022 01:21:01 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 28H1Kufu3955319; Fri, 16 Sep 2022 21:20:57 -0400 From: Tom Lane To: Peter Geoghegan cc: PostgreSQL Hackers Subject: Re: Making C function declaration parameter names consistent with corresponding definition names In-reply-to: References: <3913123.1663370391@sss.pgh.pa.us> <3922750.1663372191@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Fri, 16 Sep 2022 17:15:24 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3955317.1663377656.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Sep 2022 21:20:56 -0400 Message-ID: <3955318.1663377656@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Geoghegan 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, Trans= actionId, 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