Re: Throw some low-level C scutwork at me - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Throw some low-level C scutwork at me
Date
Msg-id 14002.1241195241@sss.pgh.pa.us
Whole thread Raw
In response to Re: Throw some low-level C scutwork at me  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Speaking of space/tab settings, one thing I'm fuzzy on is the rule for
> wrapping long lines.  I understand that a line that extends past 80
> characters has to be wrapped, but the amount of indentation on the
> continuation line doesn't appear to follow a consistent pattern - or
> does it?

I tend to let emacs indent the continuation line the way it wants.
pg_indent sometimes has a slightly different theory about that, but
it usually doesn't change it enough to be a problem.

A rough rule of thumb is that pg_indent is pretty good at horizontal
whitespace decisions and absolutely terrible at vertical decisions.
Break the lines where you want them, and put blank lines where and only
where you want them, and pg_indent will clean up the rest pretty well.

Also, I don't think that 80 columns is an inviolable limit.  I don't
generally like to break up error message strings just to keep the
ereport call to 80 columns, for instance.  (This is partly because
I know how often it comes in handy to grep the source for particular
message strings --- and breaking the string in a random place can
defeat that.)  What I do think is that the code should be easily readable
in an 80-column window.  It's usually pretty obvious when a patch author
was working in a 100-or-more-column window, if you try to read it in
80 columns ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Table data exclusion patch for pg_dump
Next
From: Andrew Dunstan
Date:
Subject: Re: Throw some low-level C scutwork at me