Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #150903

Re: Coding style for small if statements

Show all headers | View raw

Jorgen Grahn <grahn+nntp@snipabacken.se> 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.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 06:30 -0800
  Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-16 16:14 +0100
    Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-16 16:40 +0000
      Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-16 17:48 +0100
      Re: Coding style for small if statements Robert Wessel <robertwessel2@yahoo.com> - 2020-02-16 17:14 -0600
      Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-30 00:27 -0700
  Re: Coding style for small if statements Ike Naar <ike@sdf.lonestar.org> - 2020-02-16 18:39 +0000
    Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-16 20:37 +0000
      Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-17 09:09 +0100
        Re: Coding style for small if statements Öö Tiib <ootiib@hot.ee> - 2020-02-17 05:32 -0800
        Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-17 18:07 +0000
        Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-17 23:48 +0000
        Re: Coding style for small if statements Richard Damon <Richard@Damon-Family.org> - 2020-02-17 20:40 -0500
    Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-23 10:14 -0800
      Re: Coding style for small if statements Ike Naar <ike@iceland.freeshell.org> - 2020-02-23 20:16 +0000
        Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-29 18:56 -0700
          Re: Coding style for small if statements Ike Naar <ike@sdf.lonestar.org> - 2020-03-30 06:07 +0000
            Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-03-30 06:45 +0000
              Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-03-30 10:50 +0200
                Re: Coding style for small if statements gazelle@shell.xmission.com (Kenny McCormack) - 2020-03-30 13:04 +0000
                Re: Coding style for small if statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-03-30 06:17 -0700
            Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 14:09 -0700

csiph-web