Postgres Pro
Downloads
Home   >   mailing lists

Thread: coding style guidelines?

coding style guidelines?

From
Larry Rosenman
Date:
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

Re: coding style guidelines?

From
Tom Lane
Date:
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

Re: coding style guidelines?

From
Bruce Momjian
Date:
> 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,
Pennsylvania19026