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.
