This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: An abridged "Writing C" for the gcc web pages
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Bernd Schmidt <bernds_cb1 at t-online dot de>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Gerald Pfeifer <gerald at pfeifer dot com>, carlos at redhat dot com, Bernd Schmidt <bschmidt at redhat dot com>
- Date: Mon, 25 Apr 2016 21:04:58 +0100
- Subject: Re: An abridged "Writing C" for the gcc web pages
- Authentication-results: sourceware.org; auth=none
- References: <571A4F78 dot 5020200 at t-online dot de>
Bernd Schmidt <bernds_cb1@t-online.de> writes:
> (Apologies if you get this twice, the mailing list didn't like the html
> attachment in the first attempt).
>
> We frequently get malformatted patches, and it's been brought to my
> attention that some people don't even make the effort to read the GNU
> coding standards before trying to contribute code. TL;DR seems to be the
> excuse, and while I find that attitude inappropriate, we could probably
> improve the situation by spelling out the most basic rules in an
> abridged document on our webpages. Below is a draft I came up with.
> Thoughts?
The patch got some slightly negative reactions, so to balance things out:
it looks like a good intro to me FWIW. A couple of nits:
> +<p>There should be a space before open-parentheses and after commas.
> +We also use spaces around binary operators.</p>
I realise it's trying to be short, but the first rule doesn't account
for things like "((int) a + b) * 3" and "-(int) 3". Maybe "There should
be a space between a function name and the opening parenthesis?".
Doesn't cover macros of course.
> +<p>Also note that multi-line comments should always be formatted as in
> +the previous example. There should not be extra stars at the
> +beginning of new lines, and the comment text should being immediately
> +after the opening <code>/*</code>.
s/being/begin/.
Thanks,
Richard