Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: how to make a macro work as a single line if stmt without braces
Date: Mon, 30 Sep 2024 02:29:10 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 182
Message-ID: <20240929190456.954@kylheku.com>
References: <PaWdnZ3R-9zI6nP7nZ2dnZfqn_GdnZ2d@brightview.co.uk>
 <vcm16e$1hm2u$1@dont-email.me> <vcn6m8$1n1vu$1@dont-email.me>
 <86frpk3s1u.fsf@linuxsc.com> <vdajg3$1k3jr$1@dont-email.me>
 <86r0932eqj.fsf@linuxsc.com> <vdboub$1pcnk$1@dont-email.me>
 <87o746qbbg.fsf@nosuchdomain.example.com>
Injection-Date: Mon, 30 Sep 2024 04:29:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0bd1f486e8df41b2cbd0758c22f4b025";
	logging-data="2063653"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19OsYIOEGS9O6HC6dGkntSqqm9w/HHKE/8="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:Z9xpoCN75ned70HTxYC94VVmC7Q=
Bytes: 5499

On 2024-09-29, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> [...]
>> This is unreadable and unacceptable
>>
>>   if (condition) {
>>     whatever1;    /* <-- Bad! No vertical separation! */
>>     whatever2;
>>   }
>>
>>   for (abc; def; ghi) {
>>     whatever1;    /* <-- Bad! No vertical separation! */
>>     whatever2;
>>   }
>>
>> This is _immensely_ more readable
>>
>>   if (condition)
>>   {               /* <-- Good! Vertical space */
>>     whatever1;
>>     whatever2;
>>   }
>>
>>   for (abc; def; fgh)
>>   {               /* <-- Good! Vertical space */
>>     whatever1;
>>     whatever2;
>>   }
> [...]
>
> Andrey, I hope you're aware that you're stating your own personal
> preferences as if they were incontrovertible fact.
>
> Readability is a combination of the text being read and the person
> reading it.  I accept without question that *you* find K&R-style
> brace placement "unreadable and unacceptable".  A lot of experienced
> C programmers, myself included, either prefer the K&R style or
> find both styles more or less equally readable.  And many prefer
> vertically aligned braces but can deal with K&R-style braces.

For what it may be worth, the K&R style is pretty much baked into the
Awk language.  These two Awk programs are not equivalent:

/foo/
{
  foo++
}

vs:

/foo/ {
  foo++
}

The first one will print every record which contains a match
for the regular expression foo, and count every record.

The second will increment foo for every record that matches foo.

It is an undeniable fact that alignment and grouping is important
in visual design, and that use of these elements (and others)
is important in creating signs and displays that are easy to
grok at a glance.

Aligning opening and closing punctuators in programming is going
overboard though.

Here is why: we have already decided that these punctuators are
not helpful in helping us grok the structure of the code, and
instead rely on indentation.

The reason that the punctuators are not helpful is not because they are
not vertically aligned.

However, if we take away indentation from all the code other
than the braces, then the vertical alignment does help recover
some of the lost readability:

Compare:

  if (condition) {
  for (abc; def; fgh) {
  if (nested-condition) {
  whatever1;
  whatever2;
      }
    }
  } else {
  whatever3;
  }

versus:

  if (condition)
  {
  for (abc; def; fgh)
    {
  if (nested-condition)
      {
  whatever1;
  whatever2;
      }
    }
  }
  else
  {
  whatever3;
  }

But the likely reason for this is that the aligned braces increase the
amount of correct indentation. The structural cue from indentation is
only coming from the braces here, so if half of them are not indented,
then half that signal is gone.

I can sort of see why this identation signal from the opening braces
would be important even if the code were fully indented, to someone who
has some sort of cognitive quirk.

Also, I can see how the structure is more nicely conveyed when the
eopening braces are indented, if the reader temporarily blocks out
the visibility of the code and focuses on only seeing the braces:

This:

  {

    {

      {

  
      }
    }
  }

  {

  }

versus:

                 {
                      {
                        {


      }
    }
  }      {

  }

In other words, the vertical braces enable a mode of visually filtering
the code that may be of use to some. (Though, to me, choosing to see
the braces while suppressing the rest of the code seems wrongheaded. Or
wrong-eyed?)

It is mainly an indentation signal though; the main aspect is not the
vertical alignment, but the correct indentation nesting.  All the
matching braces are still vertically aligned in this code also, yet
the indentation is haphazard and unhelpful:

  if (condition)
      {
  for (abc; def; fgh)
    {
  if (nested-condition)
    {
  whatever1;
  whatever2;
    }
    }
      }
  else
       {
  whatever3;
       }

-- 
TXR Programming Language: http://nongnu.org/txr
========== REMAINDER OF ARTICLE TRUNCATED ==========