Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c
Subject: Re: Coding style for small if statements
Date: Sat, 22 Feb 2020 08:34:39 -0800
Organization: A noiseless patient Spider
Lines: 52
Message-ID: <86a75ad1i8.fsf@linuxsc.com>
References: <20200131234613.59047e037939ceb549b8e6d6@gmail.com> <65de5d07-838a-4a5f-bd70-b8a263fc61d6@googlegroups.com> <86o8tyfy0z.fsf@linuxsc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="a1e79922b2c02e9149a52088916eaff2"; logging-data="16010"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19rNvEKtOFhVC6mSxyUXZFv+Y70I6Xtd1g="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:rhLibRs2EYoapPZbkWfMA70R+Cw= sha1:No09kJiqT6ittNnIAwcOfk4mVuw=
Xref: csiph.com comp.lang.c:150151
Bart writes:
> On 16/02/2020 13:43, Tim Rentsch wrote:
>
>> John Bode writes:
>>
>>> My personal rules:
>>>
>>> 1. Only omit braces for the innermost if (when applicable),
>>> and only if it does not have an associated else;
>>> 2. Braces and else go on their own lines;
>>> 3. Braces line up with the if and else;
>>>
>>> To wit:
>>>
>>> if ( dblh != dblw )
>>> {
>>> if ( dblh )
>>> {
>>> gfx_flags |= GFX_DBL_H;
>>> }
>>> else
>>> {
>>> gfx_flags |= GFX_DBL_W;
>>> }
>>> }
>>>
>>> Unambiguous. It's clear which if the else belongs to, it's clear
>>> which branch is taken based on the conditions, etc. You won't
>>> introduce a bug if you decide to add a logging statement to either
>>> branch. It sacrifices some vertical space (and a little visual
>>> clutter), but nobody's going to come tracking you down later to
>>> ask what the hell you meant.
>>
>> Remarkable. Advocating for a way of writing that uses eleven
>> lines where a single line suffices.
>
> Five lines of code and 6 lines each containing a single brace.
>
> Despite this, this is only 50% longer than your one-liner: 75 versus
> 50 non-space characters.
A silly comparison. More lines always makes a program longer.
More characters do not, in most cases, make a program wider.
> My prefered brace style would make this 8 lines, and keeps the benefit
> of easier maintenance and easier insertion of extra statements.
If we factor in the low probability of needing to take advantage
of that flexibility, and add in the cost of extra program length
and reading time, the resulting ROI is net negative. It's always
important to look at both sides of the scale.