From Newsgroup: comp.lang.c

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

[...]

And don't use "Egyptian" braces [the style used in the
first edition of The C Programming Language, by Kernighan
and Ritchie].

This is the proper formatting style with braces

if (failed)
{
...
}
else
{
...
}

The vertical spacing introduced by the `{` line provides
separation between condition and the branch, which makes
your code much more readable. [...]

What qualities does this layout style have that make it "more
readable", other than it being one that you like or prefer?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 09/28/24 5:02 AM, Tim Rentsch wrote:

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

[...]

And don't use "Egyptian" braces [the style used in the
first edition of The C Programming Language, by Kernighan
and Ritchie].

This is the proper formatting style with braces

if (failed)
{
...
}
else
{
...
}

The vertical spacing introduced by the `{` line provides
separation between condition and the branch, which makes
your code much more readable. [...]

What qualities does this layout style have that make it "more
readable", other than it being one that you like or prefer?

Er... The answer to his question is already present in the quoted
portion of my post. "The vertical spacing introduced..."
--
Best regards,
Andrey

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Michael S <already5chosen@yahoo.com> writes:

On Sat, 28 Sep 2024 05:02:05 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

[...]

And don't use "Egyptian" braces [the style used in the
first edition of The C Programming Language, by Kernighan
and Ritchie].

This is the proper formatting style with braces

if (failed)
{
...
}
else
{
...
}

The vertical spacing introduced by the `{` line provides
separation between condition and the branch, which makes
your code much more readable. [...]

What qualities does this layout style have that make it "more
readable", other than it being one that you like or prefer?

{ at the same level of indentation as its matching }

Certainly it is true that the layout style shown has the open
brace at the same level of indentation as the matching close
brace. What about that property makes this layout "more
readable"? The statement given sounds like a tautology -
I don't see that any new information has been added.
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

On 09/28/24 5:02 AM, Tim Rentsch wrote:

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

[...]

And don't use "Egyptian" braces [the style used in the
first edition of The C Programming Language, by Kernighan
and Ritchie].

This is the proper formatting style with braces

if (failed)
{
...
}
else
{
...
}

The vertical spacing introduced by the `{` line provides
separation between condition and the branch, which makes
your code much more readable. [...]

What qualities does this layout style have that make it "more
readable", other than it being one that you like or prefer?

Er... The answer to his question is already present in the quoted
portion of my post. "The vertical spacing introduced..."

Does that mean you think this

if (failed) {

...

} else {

...

}

is just as readable? Or is it something besides the
vertical spacing that bears on your "more readable"
judgment?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 09/28/24 10:47 PM, Tim Rentsch wrote:
efer?

Er... The answer to his question is already present in the quoted
portion of my post. "The vertical spacing introduced..."

Does that mean you think this

if (failed) {

...

} else {

...

}

is just as readable? Or is it something besides the
vertical spacing that bears on your "more readable"
judgment?

No, the spacing in question is the spacing between the `if` condition
and the first line of the the first compound statement.

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;
}

This readability problem exists one the other end with struct
declarations and `do{}while` syntax as well

typedef struct MyStruct
{
int a;
double b;
char c;
} MyStruct; /* <-- Bad! No vertical separation! */

do
{
whatever1;
whatever2;
} while (condition); /* <-- Bad! No vertical separation! */

I don't have a perfect solution for this variation of the same issue.
So, I tend to use

typedef struct MyStruct
{
int a;
double b;
char c;

} MyStruct;

do
{
whatever1;
whatever2;

} while (condition);

although admittedly this has its own drawbacks.
--
Best regards,
Andrey

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

On 09/28/24 10:47 PM, Tim Rentsch wrote:
efer?

Er... The answer to his question is already present in the quoted
portion of my post. "The vertical spacing introduced..."

Does that mean you think this

if (failed) {

...

} else {

...

}

is just as readable? Or is it something besides the
vertical spacing that bears on your "more readable"
judgment?

No, the spacing in question is the spacing between the `if` condition
and the first line of the the first compound statement.

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

To you. I find it less readable than the above.

For those of us who started with ed/vi, certain paradigms
evolved - such as ensuring the function name for a function
definition starts in column 1 so you can easily find it
using /^function-name, so

int
main(...)
{
}

is preferrred over

int main(...) {
}


Likewise, the opening brace for the function should start
a line (supporting the '[[' and ']]' vim commands).

(and '%' use useful to match braces).

Indentation should be a sufficient visual cue without wasting
whitespace on useless blank lines.

f = fdopen(fd, "r");
if (f == NULL) {
lp->log("Unexpected error re-opening '%s': %s\n",
filename, strerror(errno));
close(fd);
goto done;
}
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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.

I have some quirks of my own, things that most people accept but
I hate, so I get where you're coming from. But I suggest it would
be good for you to be aware that your preferences are something of
an outlier, and that arguing about it isn't going to be productive.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

On 09/28/24 10:47 PM, Tim Rentsch wrote:
efer?

Er... The answer to his question is already present in the quoted
portion of my post. "The vertical spacing introduced..."

Does that mean you think this

if (failed) {
...
} else {

...

}

is just as readable? Or is it something besides the
vertical spacing that bears on your "more readable"
judgment?

No, the spacing in question is the spacing between the `if`
condition and the first line of the the first compound statement.

My question was misquoted. I was asking about this:

if (failed) {

...

} else {

...

}

where there is a blank line after the "if()" line, both before
and after the "} else {" line, and before the line with the final
closing brace.

This layout has as much vertical separation as the layout style
you prefer (and one more blank line at the end). Do you think it
is just as readable as your preferred layout? Or is it something
besides the vertical spacing that bears on your "more readable"
judgment?
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 2024-09-29, Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:

On 09/28/24 10:47 PM, Tim Rentsch wrote:
efer?

Er... The answer to his question is already present in the quoted
portion of my post. "The vertical spacing introduced..."

Does that mean you think this

if (failed) {

...

} else {

...

}

is just as readable? Or is it something besides the
vertical spacing that bears on your "more readable"
judgment?

No, the spacing in question is the spacing between the `if` condition
and the first line of the the first compound statement.

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;
}

I don't see a readability difference. I'm not a kook.

Both examples use correct indentation.

The braces are placed such that the indentation does not lie.

If that is the case, you don't have to care how exactly they
are placed.

When I look at this code, my brain mostly sees it like this:

if (condition)
whatever1; /* <-- Bad! No vertical separation! */
whatever2;

for (abc; def; ghi)
whatever1; /* <-- Bad! No vertical separation! */
whatever2;

if (condition)
/* <-- Good! Vertical space */
whatever1;
whatever2;


for (abc; def; fgh)
/* <-- Good! Vertical space */
whatever1;
whatever2;

except that if there is something deceptive with the braces going on,
there is a good chance my brain will still alert me to it.

"Cuddled braces" is a very popular formatting style; it behooves you to
get used to it.

This readability problem exists one the other end with struct
declarations and `do{}while` syntax as well

typedef struct MyStruct
{
int a;
double b;
char c;
} MyStruct; /* <-- Bad! No vertical separation! */

do
{
whatever1;
whatever2;
} while (condition); /* <-- Bad! No vertical separation! */

I don't have a perfect solution for this variation of the same issue.
So, I tend to use

I don't understand what would be wrong with:

do
{
whatever1;
whatever2;
}
while (condition); /* <-- Good! Vertical separation! */

For the typedef you can always do this:

typedef struct MyStruct MyStruct;

struct MyStruct
{
int a;
double b;
char c;
};
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Michael S <already5chosen@yahoo.com> writes:

On Sat, 28 Sep 2024 21:53:06 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

On Sat, 28 Sep 2024 05:02:05 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

[...]

And don't use "Egyptian" braces [the style used in the
first edition of The C Programming Language, by Kernighan
and Ritchie].

This is the proper formatting style with braces

if (failed)
{
...
}
else
{
...
}

The vertical spacing introduced by the `{` line provides
separation between condition and the branch, which makes
your code much more readable. [...]

What qualities does this layout style have that make it "more
readable", other than it being one that you like or prefer?

{ at the same level of indentation as its matching }

Certainly it is true that the layout style shown has the open
brace at the same level of indentation as the matching close
brace. What about that property makes this layout "more
readable"? The statement given sounds like a tautology -
I don't see that any new information has been added.

It makes it easier to see where block starts and where it ends.
Opening { followed by empty line is more bold visually than 'if
something { ' or then '} else {'.

Certainly having an open brace on a line by itself stands out
more than if the open brace were written at the end of an if()
or while() line.

Whether that makes it easier to see where a block starts is
something that can be measured, and also might be reader
dependent. For myself I find that having open braces on lines by
themselves interferes with my ease of reading. And that has been
true since before I ever programmed in C.

Now, I can live with both styles, but can see why many people
prefer style advocated by Andrey.

I've made a serious effort over the years to find out why people
who prefer the Andrey style are so definite that it is somehow
better. I have yet to get an illuminating answer to that
question. I've gotten various forms of non-answer arguments, and
what seem to me to be circular answers (like saying it is more
readable). I understand that they prefer it; I still don't
understand why they prefer it. I acknowledge your point that
they think the open brace on a line by itself somehow helps with
their reading. But I still don't understand why they think that.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

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
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

First, I want to re-emphasize that valuation of styles lies in the
eye of the beholder. Then, for practical purposes, there's usually (coding-)standards defined [in professional contexts] that define
the rules folks have to follow. While in private contexts everyone
is free to follow own personal preferences.

On 30.09.2024 04:29, Kaz Kylheku wrote:

[...]

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++
}

For the readers unfamiliar with Awk it should be mentioned that
this is a consequence of Awk's implicit defaults.

/foo/ is equivalent to /foo/ { print $0 }

and

{ foo++ } is equivalent to 'true' { foo++ }

(using the informal 'true' as placeholder for any true condition).

Thus you have to put the opening braces on the same line as the
condition to indicate that condition and action belong together.

[...]

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.

Sic!

[...]

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:

{

{

{


}
}
}

{

}

As far as I'm concerned, it's not only the braces but also the
placement of the associated control-structure keywords that
matters.

To _quickly_ *assert* the code structure the following...

versus:

{
{
{

}
}
} {

}

...is indeed [unnecessarily] suboptimal! (And adding the keywords
doesn't make that situation better.) Having tool support (like
an editor's syntax highlighting) might alleviate that issue (but
does not solve it).

(Maybe it's to some degree comparable with the difference between
ragged layout of texts vs. text that has consistent line lengths
or is even block-justified.)

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?)

There's nothing suppressed. (Moreover I think any tries to value
other preferences with psychological assumptions and personal
valuations doesn't serve the discussions.)

BTW, a friend of mine (a long year experienced CS professional)
prefers [to my astonishment] a formatting I've not (or certainly
not widely) seen before...

while (cond)
{
stmt1;
stmt2;
}

Also aligned (but differently).

[...]

It might make sense - besides visual or "psychological" explanations -
to also include people's experiences with or influences from other
programming languages they use. People may be used to structures like

if condition then
begin
...
end
else
...

which can be found in many languages (Algol, Pascal, ...), or from
the Unix [standard] shell where syntax requirements foster structures
like

if command1
then
command2
else
command3
fi


My personal preferences are best supported by a syntax that you
find in Algol 68, Eiffel (or Unix shell), where you usually don't
need any sort of brackets in control structures, and where there's
thus less dispute about where to place the 'opening block' symbol.

Janis

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

On 29/09/2024 16:41, Andrey Tarasevich wrote:

On 09/28/24 10:47 PM, Tim Rentsch wrote:
efer?

Er... The answer to his question is already present in the quoted
portion of my post.  "The vertical spacing introduced..."

Does that mean you think this

     if (failed) {
       ...
     } else {

       ...

     }

is just as readable?  Or is it something besides the
vertical spacing that bears on your "more readable"
judgment?

No, the spacing in question is the spacing between the `if` condition
and the first line of the the first compound statement.

This is unreadable and unacceptable

I hope you are aware that that is, at best, a personal opinion? Given
that a great many C programmers write code that way and find it both
readable and acceptable - indeed preferable to your own style - your
claim is obviously factually incorrect.

If you can provide evidence in the form of studies or statistical data
that demonstrate that your style is significantly easier to read for
many people, or leads to fewer errors in code, then I think many people
here would be interested in that. But as it stands, your post is as
useful as telling us that the best flavour of ice-cream is obviously strawberry and that chocolate ice-cream is inedible.

This readability problem exists one the other end with struct
declarations and `do{}while` syntax as well

I don't have a perfect solution for this variation of the same issue.
So, I tend to use

  typedef struct MyStruct
  {
    int a;
    double b;
    char c;

  } MyStruct;

  do
  {
    whatever1;
    whatever2;

  } while (condition);

although admittedly this has its own drawbacks.

Note that the "one true brace" style has no problem here and is
consistent in these cases. Consistency is not necessarily of overriding importance, but it often helps readability.

--- Synchronet 3.20a-Linux NewsLink 1.114

From Newsgroup: comp.lang.c

Michael S <already5chosen@yahoo.com> wrote:

On Sat, 28 Sep 2024 21:53:06 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Michael S <already5chosen@yahoo.com> writes:

On Sat, 28 Sep 2024 05:02:05 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

[...]

And don't use "Egyptian" braces [the style used in the
first edition of The C Programming Language, by Kernighan
and Ritchie].

This is the proper formatting style with braces

if (failed)
{
...
}
else
{
...
}

The vertical spacing introduced by the `{` line provides
separation between condition and the branch, which makes
your code much more readable. [...]

What qualities does this layout style have that make it "more
readable", other than it being one that you like or prefer?

{ at the same level of indentation as its matching }

Certainly it is true that the layout style shown has the open
brace at the same level of indentation as the matching close
brace. What about that property makes this layout "more
readable"? The statement given sounds like a tautology -
I don't see that any new information has been added.

It makes it easier to see where block starts and where it ends. Opening
{ followed by empty line is more bold visually than 'if something { ' or
then '} else {'.

Now, I can live with both styles, but can see why many people prefer
style advocated by Andrey.

I think it objectively true that superfluous compound statements and
opening braces on lines of their own make code less readable. Not by a
lot, but by enough.

The reason is that people are not struggling to read individual
statements (apart from raw beginners), they are struggling to read a
whole program. With the lots-of-blank-lines styles advocated by some,
less of a program will fit on a screen than with more economical styles.
That means more scrolling up and down to see what should be closely
related parts of the program.

This is more true of modern IDEs, where only a small part of the screen
is devoted to the program text, than good text editors. For example, in
Emacs (using Follow Mode) I can get 195 consecutive lines displayed
legibly and usably on my screen at once. But even with that, having superfluous vertical space occasionally makes me have to scroll.

At a high level of abstraction, what makes code difficult to understand
and debug is having to look somewhere else. The
superfluous-vertical-space styles increase that difficulty, if only a
little.
--
Alan Mackenzie (Nuremberg, Germany).

--- Synchronet 3.20a-Linux NewsLink 1.114