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: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: Jeff Law <law at redhat dot com>, Carlos O'Donell <carlos 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>, Bernd Schmidt <bschmidt at redhat dot com>
- Date: Tue, 3 May 2016 23:35:39 +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> <5727BB24 dot 2070404 at redhat dot com> <d0120ea7-53f5-bddf-7340-390943c86adf at redhat dot com> <87zis66hgx dot fsf at googlemail dot com>
On Tue, 3 May 2016, 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'd call that a bug in the tool. It shouldn't be switching between valid
formatting styles unless explicitly asked to, even if the formatting style
seen is not one the tool would itself produce from badly formatted code.
> And sometimes people split "if" conditions over multiple lines even when
> they would fit on one line, since the split version seems more readable.
> Again I wouldn't want a tool to be the final judge of which is right.
Like the above -- as long as it's correct it should be left alone even if
it's "suboptimal".
FWIW,
Maciej