Re: style change: explicitly permit braces for single statements
On Jul 12, 2020, at 9:31 PM, Greg A. Woods wrote: > > Personally I don't think there's any good excuse for not always putting > braces around all single-statement blocks. The only bad execuse is that > the language doesn't strictly require them. People are lazy, I get that > (I am too), but in my opinion C is just not really safe without them. I strongly concur, in my professional work for the past few decades the braces have never been considered optional (and neither have "extraneous" parentheses in expressions). -- Chris
Re: style change: explicitly permit braces for single statements
I've decided not to pursue this any further.
No objections if anyone else wants to take up the cause.
On 20-07-17 23:20, Alistair Crooks wrote:
| Just to get back to the original subject - fully support {} around single
| statements - have been doing that in my own code for ages.
|
| Would be great to have that codified (ha!)
|
| On Thu, 16 Jul 2020 at 12:01, Rhialto wrote:
|
| > On Thu 16 Jul 2020 at 13:08:49 -0400, Ted Lemon wrote:
| > > It sounds like we need a better tool. FWIW, when actually working on
| > > code, I've found that 120 is a better width than 80 -- with 80, there
are
| > > just too many line breaks. But I don't mean to say that your
| > > preference is wrong -- what sucks is that we have to compromise, instead
| > > of having tools that present the text the way that we want to consume
| > > it without changing anything in the underlying file. E.g. web browsers
| > > just reflow the text when you change the window width. Why don't we
| > > have this for code editors?
| >
| > I have seen an editor (I think it was google's Android development
| > environment) that even went so far as to recognize some particular
| > boilerplate Java code fragments, and abbreviated them. You could unfold
| > them if you wanted though.
| >
| > I wasn't sure if I liked that or hated it.
| >
| > -Olaf.
| > --
| > Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
| > ___ Anyone who is capable of getting themselves made President should on
| > \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
| >
Re: style change: explicitly permit braces for single statements
Just to get back to the original subject - fully support {} around single
statements - have been doing that in my own code for ages.
Would be great to have that codified (ha!)
On Thu, 16 Jul 2020 at 12:01, Rhialto wrote:
> On Thu 16 Jul 2020 at 13:08:49 -0400, Ted Lemon wrote:
> > It sounds like we need a better tool. FWIW, when actually working on
> > code, I've found that 120 is a better width than 80 -- with 80, there are
> > just too many line breaks. But I don't mean to say that your
> > preference is wrong -- what sucks is that we have to compromise, instead
> > of having tools that present the text the way that we want to consume
> > it without changing anything in the underlying file. E.g. web browsers
> > just reflow the text when you change the window width. Why don't we
> > have this for code editors?
>
> I have seen an editor (I think it was google's Android development
> environment) that even went so far as to recognize some particular
> boilerplate Java code fragments, and abbreviated them. You could unfold
> them if you wanted though.
>
> I wasn't sure if I liked that or hated it.
>
> -Olaf.
> --
> Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
> ___ Anyone who is capable of getting themselves made President should on
> \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
>
Re: style change: explicitly permit braces for single statements
On Thu 16 Jul 2020 at 13:08:49 -0400, Ted Lemon wrote: > It sounds like we need a better tool. FWIW, when actually working on > code, I've found that 120 is a better width than 80 -- with 80, there are > just too many line breaks. But I don't mean to say that your > preference is wrong -- what sucks is that we have to compromise, instead > of having tools that present the text the way that we want to consume > it without changing anything in the underlying file. E.g. web browsers > just reflow the text when you change the window width. Why don't we > have this for code editors? I have seen an editor (I think it was google's Android development environment) that even went so far as to recognize some particular boilerplate Java code fragments, and abbreviated them. You could unfold them if you wanted though. I wasn't sure if I liked that or hated it. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: style change: explicitly permit braces for single statements
> E.g. web browsers just reflow the text when you change the window
> width. Why don=E2=80=99t we have this for code editors?
Short answer: try to build it and you'll see.
Longer answer: Because the exact layout of `words' affects readability
of code far more than it does running text. Consider
Longer answer: Because the exact layout of `words' affects
readability of code far more than it does running text.
Longer answer: Because the exact layout of `words'
affects readability of code far more than it does
running text.
Longer answer: Because the exact layout of
`words' affects readability of code far more
than it does running text.
Longer answer: Because the exact layout
of `words' affects readability of code
far more than it does running text.
To a first approximation, all are equally readable.
Now consider
for (i=0;i<32;i++) ring[i] = 0;
j = 0;
for (i=0;i<32;i++) j = map[j];
for (i=0;i<10;i++)
{ ring[j] = 1;
j = map[j];
}
for (i=0;i<32;i++) ring[i] = 0; j = 0; for (i=0;i<32;i++) j =
map[j]; for (i=0;i<10;i++) { ring[j] = 1; j = map[j]; }
for (i=0;i<32;i++) ring[i] = 0; j = 0; for
(i=0;i<32;i++) j = map[j]; for (i=0;i<10;i++) { ring[j]
= 1; j = map[j]; }
for (i=0;i<32;i++) ring[i] = 0; j = 0; for
(i=0;i<32;i++) j = map[j]; for (i=0;i<10;i++) {
ring[j] = 1; j = map[j]; }
for (i=0;i<32;i++) ring[i] = 0; j = 0;
for (i=0;i<32;i++) j = map[j]; for
(i=0;i<10;i++) { ring[j] = 1; j =
map[j]; }
IMO, none of those are even close to as readable as the first one. I
suspect that even those who don't like the style of the first one will
find it more readable than any of the reflowed versions.
The problem is that introducing line breaks into code in a way that
doesn't slaughter readability is a hard problem. There are tools, like
indent, that try to partially solve it. Some of them don't do too
horrible a job, but even they fail catastrohpically in some cases (as I
remarked upthread, I've yet to see a rule that won't cripple
readability in at least a few cases.) I suspect doing it *well* is an
AI-complete problem; in support of this stance, note that humans often
disagree as to which of various alternatives is more readable, and note
also that tools like indent invariably utterly trash readability in
various extreme cases, cases in which humans have the aesthetic
judgement to realize that rules must sometimes be broken to preserve
minimal readability.
The analogous problem for text does exist, mostly with poetry.
Consider, for example, something like
Thus has it been told in the ancient recountings
Of those who before us were here
And their kinds and their ways, the Valar, most terrible,
Holy, and bless'd, and revered.
Simply reflowing that
Thus has it been told in the ancient recountings Of those who
before us were here And their kinds and their ways, the Valar,
most terrible, Holy, and bless'd, and revered.
rather mangles it. Now try to fit it into a narrow column. Just
reflowing for a narrow column gives
Thus has it been told in the ancient
recountings Of those who before us were
here And their kinds and their ways,
the Valar, most terrible, Holy, and
bless'd, and revered.
and it's not obvious, even to a human, how to lay it out so as to both
preserve the poetic structure and fit it into a narrow column. Here's
about the best I've been able to do:
Thus has it been told
in the ancient recountings
Of those who before us were here
And their kinds and their ways,
the Valar, most terrible,
Holy, and bless'd, and revered.
but even that doesn't look nearly as nice, to my eye, as the original.
I've occasionally thought about trying to build tools that treat C code
(because C is what I mostly work in these days) as a stream of C
tokens, ignoring layout, for purposes like diff. It would be much
harder to do so for purposes of code editing, because the clearest
layout depends heavily on semantics. For example, in general, I would
tend to format else-if chains more or less like this:
if (...)
...
else if (...)
...
else if (...)
...
else
...
But I've seen cases where (I think) it's clearer to do things that, in
other contexts, would look bizarre:
if (!strcmp(s,"one" )) v = 1;
else if (!strcmp(s,"two" )) v = 2;
else if (!strcmp(s,"three" )) v = 3;
else if (!strcmp(s,"ten" )) v = 10;
else if (!strcmp(s,"hundred" )) v = 100;
else if (!strcmp(s,"thousand")) v = 1000;
else badarg(s);
Making the parallel code structure into parallel visual structure is
Re: style change: explicitly permit braces for single statements
On Jul 16, 2020, at 12:16 PM, Gerhard Sittig wrote: > Text line length does matter to those of us who put several > copies of code side by side. It sounds like we need a better tool. FWIW, when actually working on code, I’ve found that 120 is a better width than 80—with 80, there are just too many line breaks. But I don’t mean to say that your preference is wrong—what sucks is that we have to compromise, instead of having tools that present the text the way that we want to consume it without changing anything in the underlying file. E.g. web browsers just reflow the text when you change the window width. Why don’t we have this for code editors?
Re: style change: explicitly permit braces for single statements
On Mon, 2020-07-13 at 09:18 -0700, Greg A. Woods wrote:
>
> At Mon, 13 Jul 2020 09:48:07 -0400 (EDT), Mouse
> wrote:
> Subject: Re: style change: explicitly permit braces for single statements
> >
> > Slavishly always
> > adding them makes it difficult to keep code from walking into the right
> > margin:
>
> These days one really should consider the right margin to be a virtual
> concept -- there's really no valid reason not to have and use horizontal
> scrolling (any code editor I'll ever use can do it on any display), and
> even most any small-ish laptop can have a nice readable font at 50x132,
> or even 50x160. (i.e. that's another style guide rule that should die)
Sorry, but I strongly have to disagree.
Text line length does matter to those of us who put several
copies of code side by side. In that scenario your total screen
size does not matter, there still is not enough room for 120
characters on a line in one of the files, or all of them. "But
_my_ screen is soo wide" only kind of works when one considers a
single file on the screen at any time, or only vertically split
windows. That's only half the truth. Even with multiple screens
you still may want to put several applications including editors
or text windows side by side, and avoid having to switch between
them, or chose which of them you can see at a time.
And no, I would not want to _have_ to side scroll, just to (start
to) see the code with runs out of the screen's right hand side.
It breaks the flow, is terribly slow and tedious to control, and
makes it hard(er) to spot matching braces that are vertically
aligned to their opening construct. While none of the flow
breaking obstacles are necessary.
There are useful cases where longer text lines are appropriate
("stupid" data tables, user visible string literals that you want
to be able to grep for when researching a bug report). Those
_are_ useful, but should remain the exception. From personal
experience I found the 80 chars limit the hardest to get used to,
but once you get it, a very useful one. Even today. Because
reasons, it's not as arbitrary as it may seem.
There is a reason why papers and web pages are laid out in
columns. It's more than just a tradition. Has to do with
readability. Really. Try to find the start of the next line after
the previous line was rather long. Even more so with the tiny
fonts that you mention above. And screens got smaller again with
mobile devices after they got bigger before. History keeps
repeating. :)
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
Re: style change: explicitly permit braces for single statements
>> if (ch == t.c_cc[VINTR]) {
>> } else {
>> if (ch == t.c_cc[VQUIT]) {
>> } else {
>> if (ch == t.c_cc[VKILL]) {
>> } else {
>> }
>> }
>> }
> For this, I would prefer
> if (ch == t.c_cc[VINTR]) {
> } else if (ch == t.c_cc[VQUIT]) {
> } else if (ch == t.c_cc[VKILL]) {
> } else {
> }
Sure. So would I. But that involves a subordinate clause (each if
except the first) that isn't brace-bracketed. Note what I wrote before
the example: "[s]lavishly always adding [braces] makes [...]"; that was
an example of readability impairment resulting from insistence on
always brace-surrounding dependent statements under all circumstances.
> In this case, perhaps even a switch might better,
Except that can't be done as a switch, because the cases aren't
compile-time constant expressions. The comment before it in the
original even calls it out as such:
/*
* Scan for special characters. This code
* is really just a big case statement with
* non-constant cases. [...]
*/
(sys/kern/tty.c, at least as of 1.227.4.2 - I simplified the code
significantly to not distract from my point).
> switch (ch) {
> case t.c_cc[VINTR]) {
> ...do INTR processing...
> break;
> };
> [...]
That is definitely not C. The syntax is wrong (it looks like a C
switch but with sh-style ) terminators on the cases) and the cases are
non-constant. I chose that example specifically because it can't be
transformed into a (C) switch; it was the first example to come to mind
of a relatively unavoidable else-if chain in live code. (My memory was
flaky; see below.)
That particular one can be transformed so it doesn't walk into the
right margin even if you _do_ insist on brace-bracketing, but it calls
for a different trick. The first way that comes to mind is
do {
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
break;
}
if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
break;
}
if (ch == t.c_cc[VKILL]) {
...do KILL processing...
break;
}
...etc...
} while (0);
Is that better? Sometimes, maybe. tty.c uses gotos; in the simplified
form we've been discussing, that would be
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
goto endcase;
}
if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
goto endcase;
}
if (ch == t.c_cc[VKILL]) {
...do KILL processing...
goto endcase;
}
...
endcase:
but that's pretty close to the bottom of my own preference list.
Amusingly, the original of the example I cited isn't actually an
example of what I was trying to cite at all. Perhaps I should have
made up something plausible but entirely fictitious, or gone and dug up
an example of a long else-if chain in real code somewhere.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
\ Email!7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: style change: explicitly permit braces for single statements
At Mon, 13 Jul 2020 09:48:07 -0400 (EDT), Mouse wrote: Subject: Re: style change: explicitly permit braces for single statements > > Slavishly always > adding them makes it difficult to keep code from walking into the right > margin: These days one really should consider the right margin to be a virtual concept -- there's really no valid reason not to have and use horizontal scrolling (any code editor I'll ever use can do it on any display), and even most any small-ish laptop can have a nice readable font at 50x132, or even 50x160. (i.e. that's another style guide rule that should die) -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpezCK6Ft2EX.pgp Description: OpenPGP Digital Signature
Re: style change: explicitly permit braces for single statements
On 2020-07-13 17:52, Paul Goyette wrote:
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
} else {
if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
} else {
if (ch == t.c_cc[VKILL]) {
...do KILL processing...
} else {
...etc
}
}
}
For this, I would prefer
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
} else if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
} else if (ch == t.c_cc[VKILL]) {
...do KILL processing...
} else {
...etc
}
I would agree. That is a more readable way, I think.
In this case, perhaps even a switch might better, assuming that all of
the t_c.cc[] are unique:
switch (ch) {
case t.c_cc[VINTR]) {
...do INTR processing...
break;
};
case t.c_cc[VQUIT]) {
...do QUIT processing...
break;
}
case t.c_cc[VKILL]) {
...do KILL processing...
break;
}
...etc
In which language would this be? It's not C at least... Syntax is
slightly broken, but case values in C must be integer constant
expression... But I agree it would be nice if C would allow more
flexible options for the case values...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Re: style change: explicitly permit braces for single statements
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
} else {
if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
} else {
if (ch == t.c_cc[VKILL]) {
...do KILL processing...
} else {
...etc
}
}
}
For this, I would prefer
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
} else if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
} else if (ch == t.c_cc[VKILL]) {
...do KILL processing...
} else {
...etc
}
In this case, perhaps even a switch might better, assuming that all of
the t_c.cc[] are unique:
switch (ch) {
case t.c_cc[VINTR]) {
...do INTR processing...
break;
};
case t.c_cc[VQUIT]) {
...do QUIT processing...
break;
}
case t.c_cc[VKILL]) {
...do KILL processing...
break;
}
...etc
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
++--+---+
Re: style change: explicitly permit braces for single statements
On Mon 13 Jul 2020 at 09:48:07 -0400, Mouse wrote: > I'd actually recommend one exception, that being the else-if chain: if > the dependent clause after an else is a single statement, and it is an > if statement, then, depending on the semantic relationship of the inner > if's test to the enclosing if's, I can go either way on whether I'd > prefer braces or no braces around the inner if. I agree with the proposal at the start of the thread and I also agree with this. I guess that some languages have a special 'elif' or 'elseif' keyword just because of this. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: style change: explicitly permit braces for single statements
>> I find the braces pure visual clutter in the latter.
> What really bugs me is when my code winds up with a security fail because I $
Yeah, that bugs me too.
But "don't be careless" isn't something codifiable enough to go on a
list of style rules such as this one.
> â??Because it looks betterâ?? is not a good reason to write less safe code. $
True as far as it goes. But, certainly for me and I suspect in
general, "it looks better" correlates positively with being safe: the
more transparent the transformation between the algorithm and the text,
the fewer places for unpleasant surprises to hide.
And, while there will of course be broad similarities, that level of
transparency depends in part on the human in question, which is part of
why we still have disagreements over style.
Not that I haven't made similar mistakes. Anyone who hasn't hasn't
written very much code. But rules cannot prevent anyone from making
mistakes. The most they can do, the very most, is have a moderate
effect on how likely various classes of mistakes are - and that takes
us right back to dependence on the human involved.
> My current coding style _requires_ braces for all dependent clauses,
> even if there is only a single statement.
I'd actually recommend one exception, that being the else-if chain: if
the dependent clause after an else is a single statement, and it is an
if statement, then, depending on the semantic relationship of the inner
if's test to the enclosing if's, I can go either way on whether I'd
prefer braces or no braces around the inner if. Slavishly always
adding them makes it difficult to keep code from walking into the right
margin:
if (ch == t.c_cc[VINTR]) {
...do INTR processing...
} else {
if (ch == t.c_cc[VQUIT]) {
...do QUIT processing...
} else {
if (ch == t.c_cc[VKILL]) {
...do KILL processing...
} else {
...etc
}
}
}
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: style change: explicitly permit braces for single statements
On Mon, Jul 13, 2020 at 09:18:18AM -0400, Ted Lemon wrote: > On Jul 13, 2020, at 9:13 AM, Mouse wrote: > > . I find the braces pure visual clutter in the latter. > > What really bugs me is when my code winds up with a security fail because I > wasn’t careful. If only we had compilers that could warn us if the indentation doesn't match the semantics of the language. Oh wait. Joerg
Re: style change: explicitly permit braces for single statements
On Jul 13, 2020, at 9:13 AM, Mouse wrote: > . I find the braces pure visual clutter in the latter. What really bugs me is when my code winds up with a security fail because I wasn’t careful. I’ve had this happen maybe three or four times in my career, which isn’t too bad, but it’s hard to catch. Once I hacked /bin/login to support Kerberos and made a mistake of this sort which allowed root logins without a password. Fortunately I caught it before anyone else noticed, not by code examination but because after many test cycles I accidentally hit return when logging in instead of typing in a password. “Because it looks better” is not a good reason to write less safe code. C is dangerous enough without taking unnecessary risks. My current coding style _requires_ braces for all dependent clauses, even if there is only a single statement.
Re: style change: explicitly permit braces for single statements
> Personally I don't think there's any good excuse for not always
> putting braces around all single-statement blocks.
Well, you may not think it good, but I prefer
if (x < 0) return(n);
to
if (x < 0) { return(n); }
. I find the braces pure visual clutter in the latter.
I also prefer
if (compute_length(end1->vtx->pt,end2->vtx->pt) < delta)
return(scale(normal,size));
to
if (compute_length(end1->vtx->pt,end2->vtx->pt) < delta)
{ return(scale(normal,size));
}
because of the vertical space saved, but I usually actually write the
latter because of software limitations - figuring out how much to
indent the second line is complicated, requiring something like a
codewalker to tell whether the second line is the consequent of the if
or a continuation of the condition. (And I prefer either of them over
if (compute_length(end1->vtx->pt,end2->vtx->pt) < delta) {
return(scale(normal,size));
}
but that's a holy war for another day.)
Ultimately, it comes down to: I prefer readbility - which is mostly an
aesthetic judgement - over strict conformance to rules. I consider
such `rules' as being there to serve, not to constrain; I think
"recommendations" would be a better word. I've yet to see a style
"rule" - my own or anyone else's - that doesn't impair readability at
least occasionally.
> [I]n my opinion C is just not really safe without [the braces].
Is C *ever* safe? (Safe from what?)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
re: style change: explicitly permit braces for single statements
> On 20-07-12 10:01, Luke Mewburn wrote: > | I propose that the NetBSD C style guide in to /usr/share/misc/style > | is reworded to more explicitly permit braces around single statements, > | instead of the current discourgement. > | > | IMHO, permitting braces to be consistently used: > | - Adds to clarity of intent. > | - Aids code review. > | - Avoids gotofail: > https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug > | > | regards, > | Luke. > > I was asked to CC this thread to tech-kern@, so I'm doing that. yes please. .mrg.
Re: style change: explicitly permit braces for single statements
At Sun, 12 Jul 2020 10:01:36 +1000, Luke Mewburn wrote: Subject: style change: explicitly permit braces for single statements > > I propose that the NetBSD C style guide in to /usr/share/misc/style > is reworded to more explicitly permit braces around single statements, > instead of the current discourgement. > > IMHO, permitting braces to be consistently used: > - Adds to clarity of intent. > - Aids code review. > - Avoids gotofail: > https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug Well, if you s/permit/require/g, I strongly concur (with possibly one tiny exception allowed in rare cases -- when there's no newline). Personally I don't think there's any good excuse for not always putting braces around all single-statement blocks. The only bad execuse is that the language doesn't strictly require them. People are lazy, I get that (I am too), but in my opinion C is just not really safe without them. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgplEU3KR6NQt.pgp Description: OpenPGP Digital Signature
Re: style change: explicitly permit braces for single statements
A few years ago when I worked at Tesla, we had to have our production code
pass a MISRA C linter: https://gimpel.com/
MISRA C requires braces even with a single clause. I'm not going to try to
justify MISRA C's rules; but only say that 'programmers in automobile /
embedded' world probably find this extra brace practice normal.
I have a 4K screen, so a few lines wasted this way... doesn't really bother
me anymore. If I were bothered, I'd make the font 1 or 2 points smaller
and get more lines. (If any of us is still using an 80 x 24 terminal --
here's a nickel:https://dilbert.com/strip/1995-06-24 )
On Sun, Jul 12, 2020 at 1:50 AM Robert Elz wrote:
> Date:Sun, 12 Jul 2020 13:01:59 +1000
> From:Luke Mewburn
> Message-ID: <20200712030159.gh12...@mewburn.net>
>
>
> | | IMHO, permitting braces to be consistently used:
> | | - Adds to clarity of intent.
> | | - Aids code review.
> | | - Avoids gotofail:
> https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug
>
>
> Permitting the braces is probably no big deal, but does none of
> that. Actually using the extra braces might, but unless you change
> "permitting" to "requiring", that's unlikely to happen a lot.
>
> I simply cannot see myself changing
>
> if (p == NULL)
> return NULL;
>
> into
>
> if (p == NULL) {
> return NULL;
> }
>
> Aside from anything else, the closing brace occupies an extra
> line (and often two, as those are often followed by blank lines)
> which means two less lines of context I get to see in my window
> (however big the window is - enlarging it still means 2 less lines
> of context than would be possible) - and that's for each time this
> is done.
>
> But as long as they're just permitted, and not required, then I
> don't have a big problem with it - but note that if I'm working
> on code written like that, I'm likely to delete non-required
> meaningless braces (just as cleaning up trailing whitespace,
> fixing tab vs space indentation, and wrapping long lines, etc).
>
> kre
>
>
Re: style change: explicitly permit braces for single statements
Date:Sun, 12 Jul 2020 13:01:59 +1000
From:Luke Mewburn
Message-ID: <20200712030159.gh12...@mewburn.net>
| | IMHO, permitting braces to be consistently used:
| | - Adds to clarity of intent.
| | - Aids code review.
| | - Avoids gotofail:
https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug
Permitting the braces is probably no big deal, but does none of
that. Actually using the extra braces might, but unless you change
"permitting" to "requiring", that's unlikely to happen a lot.
I simply cannot see myself changing
if (p == NULL)
return NULL;
into
if (p == NULL) {
return NULL;
}
Aside from anything else, the closing brace occupies an extra
line (and often two, as those are often followed by blank lines)
which means two less lines of context I get to see in my window
(however big the window is - enlarging it still means 2 less lines
of context than would be possible) - and that's for each time this
is done.
But as long as they're just permitted, and not required, then I
don't have a big problem with it - but note that if I'm working
on code written like that, I'm likely to delete non-required
meaningless braces (just as cleaning up trailing whitespace,
fixing tab vs space indentation, and wrapping long lines, etc).
kre
Re: style change: explicitly permit braces for single statements
On 12/07/2020 04:01, Luke Mewburn wrote: On 20-07-12 10:01, Luke Mewburn wrote: | I propose that the NetBSD C style guide in to /usr/share/misc/style | is reworded to more explicitly permit braces around single statements, | instead of the current discourgement. | | IMHO, permitting braces to be consistently used: | - Adds to clarity of intent. | - Aids code review. | - Avoids gotofail: https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug | | regards, | Luke. I was asked to CC this thread to tech-kern@, so I'm doing that. yes please Nick
Re: style change: explicitly permit braces for single statements
On 20-07-12 10:01, Luke Mewburn wrote: | I propose that the NetBSD C style guide in to /usr/share/misc/style | is reworded to more explicitly permit braces around single statements, | instead of the current discourgement. | | IMHO, permitting braces to be consistently used: | - Adds to clarity of intent. | - Aids code review. | - Avoids gotofail: https://en.wikipedia.org/wiki/Unreachable_code#goto_fail_bug | | regards, | Luke. I was asked to CC this thread to tech-kern@, so I'm doing that. pgpkhZ7P543V7.pgp Description: PGP signature
