coding style guidelines?
Is there any guidelines on the formatting of the C code in
PG? As I was working on guc-file.l yesterday, I noticed
some things with LONG lines (I broke some of them up).
I was wondering if there were formal standards?
Also, do we care about extraneous #include's?
(src/backend/parser/scansup.c has #include <ctype.h> which it
doesn't need on closer inspection, for example).
When I copied scansup.c into guc-file.l I added the #include
<ctype.h>, but it may not need it.
Larry
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman <ler@lerctr.org> writes:
Is there any guidelines on the formatting of the C code in
PG? As I was working on guc-file.l yesterday, I noticed
some things with LONG lines (I broke some of them up).
I was wondering if there were formal standards?
Brace layout, comment layout and indentation are all brought into line
by pg_indent, which Bruce runs at least once per release cycle.
However, I don't think pg_indent will consider breaking non-comment lines
into multiple lines, so it's up to the code author to be reasonable in
that area.
My own practice is to try to make the code look nice in an 80-column
window.
BTW, if you are writing a comment that you don't want to have
reformatted by pg_indent's rather braindead reformatter, protect it
with some dashes:
/*----------
* This text will not get reformatted.
*----------
*/
Also, do we care about extraneous #include's?
Not very much. You have to be particularly cautious about removing
system-header #includes, since what looks redundant on your platform
may not be redundant for other platforms. I think Bruce has a tool
to look for unnecessary includes of our own header files, but it
doesn't risk trying to remove system headers.
regards, tom lane
Larry Rosenman <ler@lerctr.org> writes:
Is there any guidelines on the formatting of the C code in
PG? As I was working on guc-file.l yesterday, I noticed
some things with LONG lines (I broke some of them up).
I was wondering if there were formal standards?Brace layout, comment layout and indentation are all brought into line
by pg_indent, which Bruce runs at least once per release cycle.
However, I don't think pg_indent will consider breaking non-comment lines
into multiple lines, so it's up to the code author to be reasonable in
that area.
It does wrap >80 lines.
My own practice is to try to make the code look nice in an 80-column
window.BTW, if you are writing a comment that you don't want to have
reformatted by pg_indent's rather braindead reformatter, protect it
with some dashes:/*----------
* This text will not get reformatted.
*----------
*/Also, do we care about extraneous #include's?
Not very much. You have to be particularly cautious about removing
system-header #includes, since what looks redundant on your platform
may not be redundant for other platforms. I think Bruce has a tool
to look for unnecessary includes of our own header files, but it
doesn't risk trying to remove system headers.
Yes, it does not touch system includes.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026