Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Coding style for small if statements Date: Mon, 30 Mar 2020 00:27:49 -0700 Organization: A noiseless patient Spider Lines: 80 Message-ID: <86r1xa7156.fsf@linuxsc.com> References: <20200131234613.59047e037939ceb549b8e6d6@gmail.com> <86blpyfvv6.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="a55df02cd5fec56056a84456239cb493"; logging-data="7953"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19E4xsQQmZkTzy4PRJpt3mf1hmccikS0zE=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:7rLVDjIBndq/ib554Qr4FW3kWIM= sha1:Boz4xNcHZUcm7wxL7nR3Gw0LFkw= Xref: csiph.com comp.lang.c:150903 Jorgen Grahn writes: > On Sun, 2020-02-16, David Brown wrote: > >> On 16/02/2020 15:30, Tim Rentsch wrote: >> >>> scott@slp53.sl.home (Scott Lurndal) writes: >>> >>>> Braces on a line by themselves just waste vertical space. >>> >>> Typically about 9 or 10 percent (comparing Allman style to >>> K&R style). A significant cost. >> >> It's a cost for those that pay programmers per line of code they write. >> For everyone else, extra lines are pretty cheap. >> >> Some people have good reason to think that writing code that is a bit >> more spread out reduces the risk of errors. That makes it very much >> cheaper for them to code that way. Other people think that making their >> C code look like APL reduces the likelihood that anyone but them will >> ever change their code, and this protects it from mistakes - so they see >> obfuscated code as cheaper. Most people lie somewhere between these, >> but suggesting that a wider vertical style is "costly" (rather than >> perhaps unnecessary) is either ignorance or arrogance. A good illustration of why I chose to stop reading news postings by that author. > I think the "cost" he's writing about is being able to eyeball four > and a half functions at a time, rather than five. There are several different kinds of costs. One is an effort cost: more effort is required to carry out more page turns or screen advances. Related to that is a refocusing cost: after a screen advance or a page turn, there is some visual settling time while the eyes orient to the new image. A second cost is one that you allude to, an information density cost. It helps, at least sometimes, to look at several related functions at a time. Fewer functions on the screen (or page) reduces the chances for that to happen. The impact though is larger than it might at first appear. A rule of thumb for C code is that function bodies make up roughly half of the total lines in a given source file. All of the added lines (eg, Allman vs K&R) are in function bodies, so function bodies are on average about 20% longer using an "each brace on its own line" style compared to a K&R style. If the average function body length (written using K&R layout) is 20 lines, that gives four function bodies in a 96 line screen (the overhead is two lines at the start, one line at the end, plus a blank line to separate two functions, for a total overhead of four lines per function). After a 20% expansion, the 96-line screen gives only three and not-quite one-half functions: 3*28 is 84, leaving just 12 lines on the screen for a 28-line function. (The 28 lines can be reduced to 26 lines if we are willing to disregard the final inter-function blank line and the line with the final function closing brace.) A third cost has to do with "function thrashing". The increase in function length disproportionately affects longer functions more than shorter functions. The reason is obvious: longer functions tend to make greater use of if(), for(), etc, than do shorter functions. If function bodies are on average 20% longer, then long function bodies might be 30% or 40% longer. (Disclaimer: I have no statistics on that; I'm just offering what seems like a reasonable guess.) This kind of increase raises the chances of long functions being longer than a screen's worth or a printed page. Reading such functions is harder than reading functions that fit in a single screen (or page). This observation also has a bearing on the last comment: the "half a function" (of the four) is worth somewhat less than half, because of the screen/page thrashing cost. Anecdotally, I believe there is a collateral fourth cost in terms of function length. Code that is written using an "each brace on its own line" style tends to have longer functions on average, even after adjusting for brace placement lines. Like I said, any evidence I have seen for this is purely anecdotal; I haven't done any sort of systematic investigation. So take that for what it might be worth.