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

Groups > comp.lang.c > #150051 > unrolled thread

Re: Coding style for small if statements

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 1 of 2  [1] 2  Next page →

#150051 — Re: Coding style for small if statements

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.

[toc] | [next] | [standalone]

#150054

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.

[toc] | [prev] | [next] | [standalone]

#150056

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.

I think the "cost" he's writing about is being able to eyeball four
and a half functions at a time, rather than five.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#150057

On 16/02/2020 17:40, Jorgen Grahn wrote:
> 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.
> 
> I think the "cost" he's writing about is being able to eyeball four
> and a half functions at a time, rather than five.
> 

Ultimately, for professional programmers, it's all one cost.  But no
matter how you count it, he's wrong.

[toc] | [prev] | [next] | [standalone]

#150061

On 16 Feb 2020 16:40:27 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
wrote:

>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.
>
>I think the "cost" he's writing about is being able to eyeball four
>and a half functions at a time, rather than five.


That is an area where an intelligent editor could make a difference,
by rendering blocks in an obvious, but more space efficient way.
Unfortunately I've not seen any attempts that didn't look worse than
the problem, although some of that may just be some immediate level of
visual unfamiliarity.

[toc] | [prev] | [next] | [standalone]

#150903

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.

[toc] | [prev] | [next] | [standalone]

#150058

On 2020-02-16, Tim Rentsch <tr.17687@z991.linuxsc.com> 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 /* ... */

I personally find the latter more readable because the opening and
closing braces are properly aligned.

[toc] | [prev] | [next] | [standalone]

#150059

On Sun, 2020-02-16, Ike Naar wrote:
> On 2020-02-16, Tim Rentsch <tr.17687@z991.linuxsc.com> 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

I was going to say "I often write it like that", but after checking
some of my recent source code (in C++, but still):

  369   if one-liners
  435   if (...) { followed by a non-blank line
   15   if (...) { followed by a blank line, like above

I do it with 10% of my while and for loops, though.  I think with a
more complex condition and more code in the block, an empty line
sometimes helps get the message across better.

(This also reveals what I think about automatic code reformatters.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#150063

On 16/02/2020 21:37, Jorgen Grahn wrote:
> On Sun, 2020-02-16, Ike Naar wrote:
>> On 2020-02-16, Tim Rentsch <tr.17687@z991.linuxsc.com> 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
> 
> I was going to say "I often write it like that", but after checking
> some of my recent source code (in C++, but still):
> 
>   369   if one-liners
>   435   if (...) { followed by a non-blank line
>    15   if (...) { followed by a blank line, like above
> 
> I do it with 10% of my while and for loops, though.  I think with a
> more complex condition and more code in the block, an empty line
> sometimes helps get the message across better.
> 
> (This also reveals what I think about automatic code reformatters.)
> 
> /Jorgen
> 

I think this one is interesting.  I don't believe I have noticed anyone
putting an intentional blank line at the start of a block like this - or
at least, I haven't thought of it as being intentional.  I sometimes
have blank lines to split up sections of code, just like splitting
paragraphs in prose.  But this strikes me as an odd place to actively
put a blank line.

[toc] | [prev] | [next] | [standalone]

#150065

On Monday, 17 February 2020 10:09:11 UTC+2, David Brown  wrote:
> On 16/02/2020 21:37, Jorgen Grahn wrote:
> > On Sun, 2020-02-16, Ike Naar wrote:
> >> On 2020-02-16, Tim Rentsch <tr.17687@z991.linuxsc.com> 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
> > 
> > I was going to say "I often write it like that", but after checking
> > some of my recent source code (in C++, but still):
> > 
> >   369   if one-liners
> >   435   if (...) { followed by a non-blank line
> >    15   if (...) { followed by a blank line, like above
> > 
> > I do it with 10% of my while and for loops, though.  I think with a
> > more complex condition and more code in the block, an empty line
> > sometimes helps get the message across better.
> > 
> > (This also reveals what I think about automatic code reformatters.)
> > 
> > /Jorgen
> > 
> 
> I think this one is interesting.  I don't believe I have noticed anyone
> putting an intentional blank line at the start of a block like this - or
> at least, I haven't thought of it as being intentional.  I sometimes
> have blank lines to split up sections of code, just like splitting
> paragraphs in prose.  But this strikes me as an odd place to actively
> put a blank line.

I have noticed it several times. I can write code in both styles. 
However blank lines after line with { at end do annoy me.
I want to be tolerant and don't see any rational reason how
a blank line can disturb me, but it does. 

Usually there is some configuration file in root of repo 
(like  .astylerc) that specifies the style for tools. So tools
take care when white space is used incorrectly. Seems
there just are no option to erase blank lines after { at end
of line. Hmm ... then instead of posting it I could write it
and put up a pull request to that astyle tool or some 
other. :D

[toc] | [prev] | [next] | [standalone]

#150066

David Brown <david.brown@hesbynett.no> writes:
>On 16/02/2020 21:37, Jorgen Grahn wrote:
>> On Sun, 2020-02-16, Ike Naar wrote:
>>> On 2020-02-16, Tim Rentsch <tr.17687@z991.linuxsc.com> 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
>> 
>> I was going to say "I often write it like that", but after checking
>> some of my recent source code (in C++, but still):
>> 
>>   369   if one-liners
>>   435   if (...) { followed by a non-blank line
>>    15   if (...) { followed by a blank line, like above
>> 
>> I do it with 10% of my while and for loops, though.  I think with a
>> more complex condition and more code in the block, an empty line
>> sometimes helps get the message across better.
>> 
>> (This also reveals what I think about automatic code reformatters.)
>> 
>> /Jorgen
>> 
>
>I think this one is interesting.  I don't believe I have noticed anyone
>putting an intentional blank line at the start of a block like this - or
>at least, I haven't thought of it as being intentional.  I sometimes
>have blank lines to split up sections of code, just like splitting
>paragraphs in prose.  But this strikes me as an odd place to actively
>put a blank line.

I generally only do it to set off declarations, e.g.

   if (condition) {
      uint32_t temp;

      non-blank-line-1;
      temp = lookup(value, type);
      non-blank-line-2;
   }

[toc] | [prev] | [next] | [standalone]

#150067

On Mon, 2020-02-17, David Brown wrote:
> On 16/02/2020 21:37, Jorgen Grahn wrote:
>> On Sun, 2020-02-16, Ike Naar wrote:
>>> On 2020-02-16, Tim Rentsch <tr.17687@z991.linuxsc.com> 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
>> 
>> I was going to say "I often write it like that", but after checking
>> some of my recent source code (in C++, but still):
>> 
>>   369   if one-liners
>>   435   if (...) { followed by a non-blank line
>>    15   if (...) { followed by a blank line, like above
>> 
>> I do it with 10% of my while and for loops, though.  I think with a
>> more complex condition and more code in the block, an empty line
>> sometimes helps get the message across better.
>> 
>> (This also reveals what I think about automatic code reformatters.)
>
> I think this one is interesting.  I don't believe I have noticed anyone
> putting an intentional blank line at the start of a block like this - or
> at least, I haven't thought of it as being intentional.  I sometimes
> have blank lines to split up sections of code, just like splitting
> paragraphs in prose.  But this strikes me as an odd place to actively
> put a blank line.

It's not something I usually do (see above) and I don't have a rule
about it.  Probably, what happens is I see the code looks cramped, I
stop to think for a second, and decide to add that blank line.

I managed to dig out one of my few examples.  Apologies for the C++.

    Excursion ex;
    unsigned n = 0;
    while(get(files, std::cerr, taxa, ex)) {

    	if(invert ^ matches(re, ex, matchtx)) {
    	    if(n++) std::cout << '\n';    // yes, I see the overflow bug
    	    std::cout << ex;
        }
    }

That's part of a longer function -- near the end of main().  The most
interesting things happen in the while() condition and the first if()
condition, so squeezing them together would have hurt readability. And
there's no other, better place to add a blank line (I don't want one
after the two first declarations, because they're so strongly
associated with the loop).

It's all very subjective, of course.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#150068

On 2/17/20 3:09 AM, David Brown wrote:
> On 16/02/2020 21:37, Jorgen Grahn wrote:
>> On Sun, 2020-02-16, Ike Naar wrote:
>>> On 2020-02-16, Tim Rentsch <tr.17687@z991.linuxsc.com> 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
>>
>> I was going to say "I often write it like that", but after checking
>> some of my recent source code (in C++, but still):
>>
>>    369   if one-liners
>>    435   if (...) { followed by a non-blank line
>>     15   if (...) { followed by a blank line, like above
>>
>> I do it with 10% of my while and for loops, though.  I think with a
>> more complex condition and more code in the block, an empty line
>> sometimes helps get the message across better.
>>
>> (This also reveals what I think about automatic code reformatters.)
>>
>> /Jorgen
>>
> 
> I think this one is interesting.  I don't believe I have noticed anyone
> putting an intentional blank line at the start of a block like this - or
> at least, I haven't thought of it as being intentional.  I sometimes
> have blank lines to split up sections of code, just like splitting
> paragraphs in prose.  But this strikes me as an odd place to actively
> put a blank line.
> 

The one case where I might do that is if the condition gets long and 
wraps onto multiple lines, then I may add a whitespace line to clearly 
separate the condition from the following statements, but if I do that I 
might just also move the brace down to make the line not blank.

[toc] | [prev] | [next] | [standalone]

#150189

Ike Naar <ike@sdf.lonestar.org> writes:

> On 2020-02-16, Tim Rentsch <tr.17687@z991.linuxsc.com> 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,

Up to the time of reading your posting, I don't remember ever
seeing that.  So of course I went looking.  Here are some
statistics.

Looking at C source (.c files), there were roughly 84,500 files,
with about 88.5 million lines of source, in files having at least
one control statement (if, for, while, do, or else) with an open
brace at the end of the line.  The average length is, naturally,
just under 1,050 lines.  (The files used were taken from a
conveniently available set of mostly open source code, not
selected for any particular source or reason.)

Of these files, the vast majority had no occurrences of a blank
line at the start of a nested block.

Looking at just the subset of files that have at least one instance
of a blank line at the start of a nested block, there were 6640
files holding roughly 22.8 million lines of source.  This gives an
average length of just over 3,433 lines (more than three times as
long as the average of the larger set).

Again looking at just the subset of files that have at least one
instance of a blank line at the start of a nested block, there were
15385 nested blocks with a blank line at the start, out of 1097658
possibles, or just over 1.4%.  However, the subset has a lot more
than its share of control statements with nested blocks, so even
counting the files that have no blank lines at the start of nested
block, nested blocks that start with a blank line make up almost
0.83% of the total.

> 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%.

The second is that people who prefer braces on separate lines usually
don't write if/else in the layout shown above, they write this:

    if (condition)
    {
        do_this();
        do_that();
    }
    else /* ... */

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 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?

[toc] | [prev] | [next] | [standalone]

#150190

On 2020-02-23, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Ike Naar <ike@sdf.lonestar.org> writes:
>
>> On 2020-02-16, Tim Rentsch <tr.17687@z991.linuxsc.com> 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.

> [...]
>
> 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.

> 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.

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?

[toc] | [prev] | [next] | [standalone]

#150899

Ike Naar <ike@iceland.freeshell.org> writes:

> On 2020-02-23, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Ike Naar <ike@sdf.lonestar.org> writes:
>>
>>> On 2020-02-16, Tim Rentsch <tr.17687@z991.linuxsc.com> 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.

[toc] | [prev] | [next] | [standalone]

#150901

On 2020-03-30, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> 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?

I can give you a reason why I find it more readable:
the vertical alignment of corresponding opening and closing braces
makes it easier to see that they form a pair.

Question to you, as a follower of K&R style:
You don't see much gain in putting the opening brace on a line by itself.
What is the benefit of putting the closing brace on a line by itself?

[toc] | [prev] | [next] | [standalone]

#150902

On Mon, 2020-03-30, Ike Naar wrote:
> On 2020-03-30, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> 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
...
>
> I can give you a reason why I find it more readable:
...

I hope this doesn't reboot the /whole/ discussion from February ...

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#150904

On 30/03/2020 08:45, Jorgen Grahn wrote:
> On Mon, 2020-03-30, Ike Naar wrote:
>> On 2020-03-30, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> 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
> ...
>>
>> I can give you a reason why I find it more readable:
> ...
> 
> I hope this doesn't reboot the /whole/ discussion from February ...
> 

Tim has risen from his slumber to resurrect a raft of old threads.  You
can expect a reply or two, then he will go back to sleep for another month.

[toc] | [prev] | [next] | [standalone]

#150905

In article <r5sbrt$35j$1@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
>On 30/03/2020 08:45, Jorgen Grahn wrote:
>> On Mon, 2020-03-30, Ike Naar wrote:
>>> On 2020-03-30, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>> 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
>> ...
>>>
>>> I can give you a reason why I find it more readable:
>> ...
>> 
>> I hope this doesn't reboot the /whole/ discussion from February ...
>> 
>
>Tim has risen from his slumber to resurrect a raft of old threads.  You
>can expect a reply or two, then he will go back to sleep for another month.
>
>

Maybe he actually has a life outside this newsgroup.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/IceCream

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web