Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Taming The Switch-Statement Date: Sat, 17 Oct 2026 19:25:54 -0700 Organization: A noiseless patient Spider Lines: 65 Message-ID: <8633u3pwwd.fsf@linuxsc.com> References: <119qf6l$2rmg3$1@dont-email.me> <20261010230355.00005189@yahoo.com> <864iesjx6e.fsf@linuxsc.com> <11afvqt$2kloc$1@dont-email.me> <11ag37o$2ln0a$1@dont-email.me> <11agbsh$2pbk7$1@dont-email.me> <11aggaq$2qqh9$1@dont-email.me> <11agils$2s3tg$1@dont-email.me> <11agv1t$30q22$2@kst.eternal-september.org> <20261012220256.00003d07@yahoo.com> <11ajb95$3t8jj$1@dont-email.me> <20261012223144.00000f95@yahoo.com> <11akm9q$29tpl$1@paganini.bofh.team> <11am99u$ul56$2@dont-email.me> <11atfif$38b7p$1@paganini.bofh.team> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 18 Oct 2026 02:25:57 +0000 (UTC) Injection-Info: dont-email.me; logging-data="831245"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18AnuwwN5S2R/f+3PopcFcC246QJr3AwG4="; posting-host="4aa5223b11d918541ec8ae2de52d32b7" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:jyPrSUf/w01sYXd6AZ7jzbOt10w= sha1:HwAceTAIKpm2e/dUJh2eGr9bMH0= sha256:lLZyz4SOdG1P11BMdMS6zvclvt5FdSCJr4Phw0FtdOQ= sha1:Zxvv8POl6sATudtOARX+wqEpbc0= sha256:uCQTFat5VfG9uAHHOo/2BOad5XaE9oITXZc4TWFaQm4= Xref: csiph.com comp.lang.c:403249 antispam@fricas.org (Waldek Hebisch) writes: > Lawrence D?Oliveiro wrote: > >> On Tue, 13 Oct 2026 07:23:40 -0000 (UTC), Waldek Hebisch wrote: >> >>> So what those counts indicate: majority of loops is simple, that is >>> have no early exit. Vast majority of early exits is done via >>> 'return'. >> >> My experience in my own C code is quite the opposite. Lots of loops >> have exits in the middle, leading me to use forms like ?for (;;)?. I >> also try to avoid putting ?return? anywhere other than the end of a >> function, to make it easier to see the flow of control. > > Well, usually there is a lot of loops. Those with exit in the > middle are still significant. > > Concernig 'return', having it in place where all work inside function > is done help me to see flow control and avoids complications. In > case of search functions it means return from the middle of the loop. > IMO possible alternatives like flag variables or break and retrun > after loop are worse. I rarely use 'break' to exit a loop. Part of this is that I try to write standard loops so that they complete as part of the loop test (i.e., in while() or for() control expressions). That isn't the whole story though so let me talk about 'return'. Most of the functions I write have exactly one return, at the end of the function. I estimate this pattern accounts for around 85% of all functions, let's say plus or minus 5%. Sometimes functions have early returns for errors or exceptional conditions. Early returns are easily seen to lie outside the main body of function processing so they don't interfere with understanding what the rest of the function is doing or how it works. A fairly common sub-pattern are functions most of whose body is a switch() statement, with all of the switch() cases being a simple return. It does sometimes happen that a function will have a loop with a return in the middle, and also a return at the end for what to do if the loop terminates. To me having an in-loop return looks better than using an assignment and a break. A fairly rare but important pattern is what I might call vectoring or decomposition. Here the function body serves to distinguish and separate out different regimes of subprocessing. To continue processing in a particular regime, a return is used not to directly yield a value but rather to call a further function to handle that sub-domain. The benefit here is both to keep function bodies small and to allow re-use of commonly called sub-functions. Two aspects are important for having these different styles work together. One is that it's easy to distinguish the different kinds of patterns, and by far the most simple pattern is the most common. The other is to be sure to keep function bodies small. Keeping function bodies small goes a long way in making them easy to understand, which obviously is a key property in writing good code. Also keeping function bodies small effectively prevents mixing different styles in a single function, serving to reinforce point one.