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: Sun, 29 Mar 2020 18:56:17 -0700 Organization: A noiseless patient Spider Lines: 144 Message-ID: <86v9mm7ghq.fsf@linuxsc.com> References: <20200131234613.59047e037939ceb549b8e6d6@gmail.com> <86blpyfvv6.fsf@linuxsc.com> <86k14db27f.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="15616"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19wGWdjrNoQpAn2ozrEJTa25fDTvfuMoHY=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:SOZdPWYE9kV7nHPwrlaE+iat7TU= sha1:IYL1D0gpjBhaezbZ+ZeNJTqjJp0= Xref: csiph.com comp.lang.c:150899 Ike Naar writes: > On 2020-02-23, Tim Rentsch wrote: > >> Ike Naar writes: >> >>> On 2020-02-16, 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. >>> >>> Curiously, one often sees >>> >>> if (condition) { >>> >>> do_this(); >>> do_that(); >>> } else /* ... */ >>> >>> which has no brace on a line by itself, >> >> [...] >> >>> but wastes the same amount of vertical space as >>> >>> if (condition) >>> { >>> do_this(); >>> do_that(); >>> } else /* ... */ >> >> There are a few problems with this reasoning. >> >> The first is that blank lines at the start of nested (K&R-style) >> blocks are rare, statistically speaking, so the space wasted is >> not the same in the two cases. The average percentage of blank- >> line-started nested blocks is just over 21%. That means overall >> lengthenings of 2.1% versus 10%. > > Both versions use the same amount of vertical space (five lines), > independent of how frequent either version occurs. That's true but I don't know why you think that's significant. Obviously if one form is used more often than the other it will have a greater impact. >> [...] >> >> Also there is the question of consistency. Are you suggesting that >> only those blocks that would have a blank line at the start be >> written with brace on a line by itself? Or that all nested blocks >> be written with brace on a line by itself? The first would be >> inconsistent. The second would be longer than the existing code >> that (sometimes) uses blank lines at the start of nested blocks. > > There is also an inconsistency in placing the opening brace at the > end of a line to save vertical space, and then putting an empty > line below that, which costs vertical space. My decision to follow K&R style (which predates K&R incidentally) does not originate from a desire to save space. I consider the space used by putting open braces on lines by themselves (eg, what is sometimes called "Allman style") to be a cost with no particular benefit, but that's not why I put open braces on the same lines as if(), etc. Also, I don't put blank lines at the start of nested blocks. I don't remember ever having done that. I see that it is done in other code, with a frequency of roughly around 1%, but I don't do that myself. Now, if you want to say that sometimes putting a blank line in those places, but usually not, is an inconsistency, my reaction is that view seems a little strange. It is common even in moderately sized function bodies to put in blank lines to indicate logical breaks in the mental flow. Apparently people who do sometimes put blank lines as the first line of a nested block do so for much the same reasons as adding blank lines in other places. Putting in blank lines /sometimes/ adds (or at least can add) useful information. Putting in blank lines /always/ would in that respect be consistent, but it adds no information, so the value is lost. Oh I see I already said more or less the same thing in my earlier posting. >> There is also another consideration. In code that /sometimes/ >> starts nested blocks with a blank line, the choice to put in a >> blank line conveys extra information. If nested blocks always >> write brace on a line by itself, the mostly empty brace lines >> don't convey that extra information. >> >>> I personally find the latter more readable because the opening >>> and closing braces are properly aligned. >> >> How much of that is just because it's what you are more used to? >> I understand there is a non-trivial hysteresis. However, if you >> run a trial period of, say, three months, during which time you >> work exclusively with K&R-style bracing, what effect does that >> have on your sense of the relative readability of the two >> styles? > > Every style has its pros and cons. Saving vertical space might be > a pro, but so might be the alignment of opening and closing braces. > Choosing a certain style, in this case, is a trade-off, you win > one good thing and lose the other. I don't understand the gain of putting open braces on lines by themselves. I've asked lots of people who choose to write code in that style what they think the benefits are, but the answers I've gotten always seem circular in one way or another. "I like it because it's more readable" sounds suspiciously like "I like it because I like it." My asking the question is not meant to be argumentative. I ask because I want to understand other people's views. So far though as best I can make out the reason is they like it because that's what they are used to. Can you shed any more light on this question? > By the way, is using vertical space really that bad? > Is using horizontal space bad? > The original piece of code could have been written as > > if(condition){do_this();do_that();}else/*...*/ > > and it would not waste any space. Would you consider this version > readable after a three-month trial period? This strikes me as being a rhetorical question. Obviously some amount of white space, both horizontal and vertical, offers a good ROI in terms of space used versus other benefits. The question is what benefits derive specifically from putting open braces on lines by themselves? If the only benefit is that this style is what someone is used to, then becoming used to a different style would have value. I hope you don't think that people avoid writing code like the code line shown above only because they aren't used to it. Also, let me say again: my decision to put open braces on the same lines as if(), etc, is not about wanting to save space. Taking extra space by putting open braces on lines by themselves incurs a non-trivial cost but that's not why I don't do it.