This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: An abridged "Writing C" for the gcc web pages


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]