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: Carlos O'Donell <carlos at redhat dot com>
- To: Bernd Schmidt <bschmidt at redhat dot com>, Jeff Law <law at redhat dot com>, Bernd Schmidt <bernds_cb1 at t-online dot de>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Gerald Pfeifer <gerald at pfeifer dot com>, rdsandiford at googlemail dot com
- Date: Tue, 3 May 2016 20:47:40 -0400
- 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> <5727BB24 dot 2070404 at redhat dot com> <d0120ea7-53f5-bddf-7340-390943c86adf at redhat dot com> <87zis66hgx dot fsf at googlemail dot com> <57292890 dot 8020905 at redhat dot com>
On 05/03/2016 06:39 PM, Bernd Schmidt wrote:
> On 05/03/2016 09:59 PM, Richard Sandiford wrote:
>>
>> And sometimes there are multiple acceptable ways of writing the
>> same code. Which wins is an aesthetic choice, which tools tend to
>> be bad at handling. E.g. if a parameter list is too long for a
>> line, there's often a choice of how to balance the parameters
>> across multiple lines, with some being more readable than others.
>> I wouldn't want the one chosen by a formatting tool to be the only
>> acceptable one.
>
> I have all the same reservations about using tools for this. We don't
> call it "style" for nothing, it is not purely mechanical and until we
> have general-purpose AI I don't believe computers can do a
> satisfactory job. I've seen attempts to do so in the past, and they
> have failed - you invariably end up with humans contorting their code
> to have it pass the checker, which is entirely counterproductive.
This would be silly. I'd never impose the tool as a commit blocker.
We have strayed from the initial goal: Help new developers submit
well formatted patches, and learn by example using a tool.
--
Cheers,
Carlos.