Re: Spacing of options in getopt_long processing

On 04.11.25 20:32, Andrew Dunstan wrote:
> Over at [1] Vaibhav complained that the patch was deleting a line 
> following one of the case branches for handling command line options in 
> pg_restore.c, and said this was not pertinent to the patch. That's 
> reasonable, but it made me look into $subject a bit. pg_restore.c has a 
> mixture, with some options being followed by blank lines and some not. 
> pg_dumpall.c and pg_dump.c have a blank line after each option, while 
> psql's startup.c has none. It would be nice to clean this up and have a 
> consistent style. But what style? Personally I think having a blank line 
> after each option looks cleaner, and we're not nearly so concerned with 
> preserving vertical space as we might once have been. I haven't surveyed 
> other utilities in our suite. Is this worth even pursuing? Do we care 
> about making each file consistent, or making all the code consistent?

I think it depends.  For example, looking through getopt_long() in 
initdb.c or pg_receivewal.c, each option processing is very simple. 
Would adding blank lines there add anything in terms of clarity?  I 
doubt it.  But then there is pg_resetwal.c, where each option processing 
is rather complex, and so the extra blank lines seem almost necessary.

Along those lines, I would suggest that pg_waldump.c adds some blank 
lines, but perhaps pg_rewind.c could remove them.

Only what pg_restore.c is doing is clearly wrong. ;-)

I am mindful of the vertical space.  Horizontal space is rather cheaper 
and the stuff toward the right is usually less important, but that 
doesn't apply vertically.