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.