Recommended Coding Style?

Recommended Coding Style?

[Jan Janak]

Hi Guys,

Is there any recommended coding style for the C/C++ code in notmuch?

  -- Jan

Re: Recommended Coding Style?

[Chris Wilson]

Excerpts from Jan Janak's message of Fri Nov 20 15:08:31 +0000 2009:
> Is there any recommended coding style for the C/C++ code in notmuch?

My prediction is that Carl will go with something close to what he wrote
for Cairo:

  http://cgit.freedesktop.org/cairo/tree/CODING_STYLE

He may or may not change to a more kernel style, but he definitely will
not mandate 3-space indents. ;-)
-ickle
-- 
Chris Wilson, Intel Open Source Technology Centre

Re: Recommended Coding Style?

[Carl Worth]

On Fri, 20 Nov 2009 15:15:16 +0000, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Excerpts from Jan Janak's message of Fri Nov 20 15:08:31 +0000 2009:
> > Is there any recommended coding style for the C/C++ code in notmuch?
> 
> My prediction is that Carl will go with something close to what he wrote
> for Cairo:
> 
>   http://cgit.freedesktop.org/cairo/tree/CODING_STYLE
> 
> He may or may not change to a more kernel style, but he definitely will
> not mandate 3-space indents. ;-)

I think Chris is right on this.

I'll adapt that CODING_STYLE document at some point and bring it into
the repository. And I probably will convert the indentation from
4-column indents (with mixed spaces and tabs) to 8-column indents (with
tabs only).

One thing that people might find a bit different are that I like to put
a space between a function name and the left parenthesis introducing
it's arguments.

That is, just as we have a space here:

	if (condition) {
		...
	}

I like one here as well:

	foo = some_function (value);

Most of the patches coming in have been fine so far. (Some have used
tabs only for indentation and I've just silently cleaned those up for
now, since I'm considering switching to that style anyway at some
point.)

One style point I would like to insist on is that commit messages should
always have more than the first, single-line summary.

The single line summary is good about saying *what* the commit does, but
I always want to see at least one sentence about the *why* as well.

I'll likely start bouncing patches that don't have that.

Thanks for the question, Jan.

-Carl