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 compel
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