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

Groups > comp.lang.c > #150899

Re: Coding style for small if statements

Show all headers | View raw

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.

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