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.