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

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

Coding style for small if statements

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

Contents

  Coding style for small if statements Anton Shepelev <anton.txt@gmail.com> - 2020-01-31 23:46 +0300
    Re: Coding style for small if statements Anton Shepelev <anton.txt@gmail.com> - 2020-01-31 23:54 +0300
      Re: Coding style for small if statements Les Cargill <lcargill99@comcast.com> - 2020-01-31 19:13 -0600
      Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 07:52 -0800
    Re: Coding style for small if statements Anton Shepelev <anton.txt@gmail.com> - 2020-02-01 00:06 +0300
      Re: Coding style for small if statements mathog <dmathog@gmail.com> - 2020-02-28 10:20 -0800
    Re: Coding style for small if statements Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-31 16:28 -0500
    Re: Coding style for small if statements donalhambra@gmail.com - 2020-02-01 04:55 -0800
      Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-01 17:16 +0000
        Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-02 11:03 -0800
          Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-03 02:20 +0000
        Re: Coding style for small if statements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-03 05:17 +0100
          Re: Coding style for small if statements chad <cdalten@gmail.com> - 2020-02-03 04:07 -0800
            Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-03 12:59 -0800
              Re: Coding style for small if statements chad <cdalten@gmail.com> - 2020-02-03 20:54 -0800
    Re: Coding style for small if statements nobody@example.org (Scott) - 2020-02-01 16:44 +0000
    Re: Coding style for small if statements already5chosen@yahoo.com - 2020-02-02 04:40 -0800
    Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-02 15:47 +0100
    Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-03 23:56 +0000
      Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 05:34 -0800
        Re: Coding style for small if statements Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-16 16:17 +0000
          Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 08:28 -0800
    Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 21:52 -0800
      Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 22:07 -0800
        Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 22:22 -0800
          Re: Coding style for small if statements skybuck2000@hotmail.com - 2020-02-03 22:25 -0800
          Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 02:35 +0000
            Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-04 20:20 -0800
              Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-05 01:04 -0500
              Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-05 01:05 -0500
    Re: Coding style for small if statements John Bode <jfbode1029@gmail.com> - 2020-02-05 12:50 -0800
      Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-05 23:36 +0000
        Re: Coding style for small if statements John Bode <jfbode1029@gmail.com> - 2020-02-06 15:01 -0800
          Re: Coding style for small if statements Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-06 15:43 -0800
            Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-07 11:02 +0100
              Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 15:24 +0000
                Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 23:03 +0000
                  Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 23:59 +0000
                    Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-08 00:16 +0000
                      Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-08 02:26 +0000
            Re: Coding style for small if statements Les Cargill <lcargill99@comcast.com> - 2020-02-08 17:07 -0600
              Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-08 23:17 +0000
                Re: Coding style for small if statements Les Cargill <lcargill99@comcast.com> - 2020-02-08 18:32 -0600
                  Re: Coding style for small if statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-09 09:32 -0800
              Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 07:10 -0800
          Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 01:26 +0000
            Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-07 11:30 +0100
              Re: Coding style for small if statements chad <cdalten@gmail.com> - 2020-02-07 05:36 -0800
              Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-07 23:36 +0000
                Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-08 17:20 +0100
                  Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 02:07 +0000
                    Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-09 13:01 +0100
                      Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-09 13:26 +0000
                        Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 15:53 +0000
                        Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-09 17:03 +0100
                      Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 15:35 +0000
                        Re: Coding style for small if statements Manfred <noname@add.invalid> - 2020-02-09 18:07 +0100
                          Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:17 +0000
                          Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-11 07:19 +0000
                            Re: Pre- and post- conditions (was Re: Coding style for small if statements) Öö Tiib <ootiib@hot.ee> - 2020-02-10 23:40 -0800
                              Re: Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-12 12:24 +0000
                            Re: Pre- and post- conditions (was Re: Coding style for small if statements) Bart <bc@freeuk.com> - 2020-02-11 11:30 +0000
                            Re: Pre- and post- conditions (was Re: Coding style for small if statements) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-02-11 09:41 -0700
                            Re: Pre- and post- conditions (was Re: Coding style for small if statements) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-12 08:12 -0500
                              Re: Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-14 21:18 +0000
                              Re: Pre- and post- conditions (was Re: Coding style for small if statements) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 00:01 -0800
                                Re: Pre- and post- conditions (was Re: Coding style for small if statements) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-22 05:22 -0800
                                  Re: Pre- and post- conditions (was Re: Coding style for small if statements) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:57 -0700
                                    Re: Pre- and post- conditions (was Re: Coding style for small if statements) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:28 -0700
                            Re: Pre- and post- conditions (was Re: Coding style for small if statements) jadill33@gmail.com - 2020-02-12 07:56 -0800
                              Re: Pre- and post- conditions (was Re: Coding style for small if statements) chad <cdalten@gmail.com> - 2020-02-12 08:57 -0800
                            Re: Pre- and post- conditions (was Re: Coding style for small if statements) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-02-14 21:31 +0000
                              Re: Pre- and post- conditions (was Re: Coding style for small if statements) jadill33@gmail.com - 2020-02-14 14:10 -0800
                                Re: Pre- and post- conditions (was Re: Coding style for small if statements) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-15 03:06 +0000
                        Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-09 19:45 +0100
                          Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:50 +0000
                            Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-09 22:51 +0000
                              Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 01:39 +0000
                                Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 09:55 +0100
                                  Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-10 11:07 +0000
                                    Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 12:48 +0100
                                      Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-10 13:13 +0000
                                        Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 15:15 +0100
                                      Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 15:46 +0000
                              Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-09 18:18 -0800
                            Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-10 09:12 +0100
                              Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 14:51 +0000
                                Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 16:19 +0000
                        Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-09 21:00 +0000
                          Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:29 +0000
                            Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-09 17:14 -0800
                        Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-09 21:15 +0000
                          Re: Coding style for small if statements James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-02-09 18:43 -0500
                            Re: Coding style for small if statements Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-02-10 01:25 +0000
                              Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 01:19 -0800
      Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 05:43 -0800
        Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-16 14:01 +0000
          Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 08:34 -0800
    Re: Coding style for small if statements Guillaume <message@bottle.org> - 2020-02-07 15:25 +0100
      Re: Coding style for small if statements Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-02-07 07:22 -0800
        Re: Coding style for small if statements Anton Shepelev <anton.txt@g{oogle}mail.com> - 2020-02-14 15:21 +0300
          Re: Coding style for small if statements Bart <bc@freeuk.com> - 2020-02-14 13:35 +0000
          Re: Coding style for small if statements Guillaume <message@bottle.org> - 2020-02-14 14:43 +0100
            Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-15 12:08 +0100
            Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-20 10:10 -0800
              Re: Coding style for small if statements David Brown <david.brown@hesbynett.no> - 2020-02-20 19:58 +0100
        Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 05:55 -0800
      Re: Coding style for small if statements scott@slp53.sl.home (Scott Lurndal) - 2020-02-07 15:26 +0000
        Re: Coding style for small if statements luser droog <luser.droog@gmail.com> - 2020-02-07 17:47 -0800
          Re: Coding style for small if statements jadill33@gmail.com - 2020-02-10 07:09 -0800
        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
      Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-18 02:09 -0800
    Re: Coding style for small if statements Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2020-02-10 01:47 +0000
    Re: Coding style for small if statements Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-12 17:54 +0100
    Re: Coding style for small if statements Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-20 07:18 -0800
    Re: Coding style for small if statements fir <profesor.fir@gmail.com> - 2020-02-29 03:30 -0800

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#150020

Malcolm McLean:

> K and R were producing a printed book. In print, the
> matched brace with the brace the only thing on the line
> style looks typographically odd, as well as consuming
> paper.

The Horstman indentation style combines proper brace
alignmment and brevity:

if (test)
{  Do();
   it();
}
else
{  DoNot();
   do();
   it();
}

https://en.wikipedia.org/wiki/Indentation_style#Horstmann_style

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#150021

On 14/02/2020 12:21, Anton Shepelev wrote:
> Malcolm McLean:
> 
>> K and R were producing a printed book. In print, the
>> matched brace with the brace the only thing on the line
>> style looks typographically odd, as well as consuming
>> paper.
> 
> The Horstman indentation style combines proper brace
> alignmment and brevity:
> 
> if (test)
> {  Do();
>     it();
> }
> else
> {  DoNot();
>     do();
>     it();
> }
> 
> https://en.wikipedia.org/wiki/Indentation_style#Horstmann_style
> 

Your example illustrates how all braces could be eliminated except the last:

  if (test)
     Do();
     it();
  else
     DoNot();
     do();
     it();
  }

while still keeping the block structure clear and unambiguous (excepting 
the fact that C has this business with 0/1 statements or N statements in 
a block, and 0/1 statements have optional braces).

Some languages just replace that final } with, for example, 'endif'; 
while Python eliminates that too.

The article in your link also illustrates how much trouble has been 
expended working out how best to keep all those pesky braces out of the 
way of the code.

(Counter-argument: some brace-less languages introduce 'then', 'do' or 
':' before the first block, but there seems a lot less controversy about 
the placement of that. Usually it's at the end of the first line. And in 
the case of C-style, it replaces the closing ")" that C requires for 
if/while/for)

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

#150022

Le 14/02/2020 à 13:21, Anton Shepelev a écrit :
> Malcolm McLean:
> 
>> K and R were producing a printed book. In print, the
>> matched brace with the brace the only thing on the line
>> style looks typographically odd, as well as consuming
>> paper.

I get that point (although I'm not convinced classic typography rules 
should apply to software code).

> The Horstman indentation style combines proper brace
> alignmment and brevity:
> 
> if (test)
> {  Do();
>     it();
> }
> else
> {  DoNot();
>     do();
>     it();
> }
> 
> https://en.wikipedia.org/wiki/Indentation_style#Horstmann_style

Indeed. I don't much like it either, though. But of course that's personal.

My style is basically the Allman style.

And generally speaking, I don't like styles trying to save space. The 
resulting code usually looks much too compact, which makes it harder to 
read. Likewise, I liberally use blank lines to separate sections of 
code, much like you would do with natural text. It helps reading 
tremendously IMO. And any modern computer screen allows to see enough 
code like this. If you ever have functions/functional blocks of code 
that are longer that what can fit this way on a typical screen, you 
probably have another style problem anyway.

Just my opinion of course, I know how controversial (and personal) this 
all is, which is attested by the mere number of different recognized 
styles in existence.

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

#150032

On 14/02/2020 15:10, Stefan Ram wrote:
> Guillaume <message@bottle.org> writes:
>> And generally speaking, I don't like styles trying to save space. The
>> resulting code usually looks much too compact, which makes it harder to
>> read.
> 
>    I'm giving courses. When I have long programs, like,
> 
> if( x )
> {
> 
>    printf( "x" );
> 
>    }
> 
>    , I need to use a smaller font so that the relevant part
>    still fits on the screen/slide (displayed via a video projector).
> 
>    When programs are smaller in height, like,
> 
> if( x )printf( "x" );
> 

Stefan, I know these things are personal, but I have to say your 
indentation, spacing and layout rules are amongst the least pleasant I 
have ever known.  You are consistent - which is good, of course.  But I 
find it ugly on the eye, and hard to follow where lines, blocks, and 
even keywords and identifiers start and stop.  The flow of text and 
spaces simply does not match the flow of the code, IMHO.

Have you ever seen a style similar to yours in use elsewhere?  Many of 
the other styles proposed here are at least related to common style 
standards.  People can refer to that Wikipedia page and say "I use 
Horstman", or "I use a variation on K&R".  Is your style entirely your 
own, or is it based on something else?

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

#150092

ram@zedat.fu-berlin.de (Stefan Ram) writes:

[...]

> There are several different ways to format texts with braces
> and parentheses.  [...]
>
> from Kernighan's B tutorial from 1972:
>
>       if(---)
>         { -----
>           ----- }
>        else if(---)
>         { -----
>           ----- }
>        else if(----)
>         { -----
>           ----- }

This choice of example is misleading.  The code outline shown is
given in the tutorial as part of explaining how 'else if' can be
used to select one choice from among several alternatives, not as
an example of layout style.  All other code shown in the tutorial
uses K&R bracing style, where the braces go on the same lines as
the 'if's or 'else's, except of course for the last where it goes
on a line by itself.  As far as compactness (which was mentioned
in the ...  text) goes, writing this example using K&R style

    if(---){
        -----
        -----
    } else if(---){
        -----
        -----
    } else if(----){
        -----
        -----
    }

takes just one additional line.  Also the closing braces line up
vertically with the statements that start the nested block.
There is quantitative evidence that lining up group closings (ie,
the close braces in C) in this way gives lower error rates than
other choices of positioning group closings.  In particular, a
closing brace style like this 

    {
      -----
      -----
    }

gives better results, in terms of observed error rates, than a
Lisp closing brace style, like this

    {
      -----
      ----- }

(I have deliberately left off a leading if() or while(), etc, to
avoid going off an a tangent about where open braces should go.)

The results regarding error rates for different closing positions
were already known well over forty years ago, so there is no excuse
for making any other choice going forward.

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

#150094

On 20/02/2020 19:10, Tim Rentsch wrote:

> The results regarding error rates for different closing positions
> were already known well over forty years ago, so there is no excuse
> for making any other choice going forward.
> 

Do you have any links or references here that we could look at?

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

#150048

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, 7 February 2020 14:25:28 UTC, Guillaume  wrote:
>
>> Small digression:
>> Not to trigger a flamewar here, I know this is a topic for potentially
>> heated debate here (coding style almost always is), but I personally
>> just hate the opening braces at the end of lines.  This style has become
>> pervasive.  I think it initially comes from the Kernighan & Richie style,
>> which granted were the authors of C, but we have to keep in mind that in
>> the 70's, screen estate was really at a premium, so it saved extra
>> lines.
>
> K and R were producing a printed book.  In print, the matched brace with
> the brace the only thing on the line style looks typographically odd, as
> well as consuming paper.

The first point is debatable, but in any event neither of these
factors influenced the way code was written in K&R, which was
written the same way they had for years been used to writing
their own programs.

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

#149825

Guillaume <message@bottle.org> writes:
>Le 31/01/2020 à 21:46, Anton Shepelev a écrit :
>> Hello, all
>> 
>> What do you think about the formatting and readability of
>> the following code of mine from a display-setup function for
>> the DOSBox emulator:
>> 
>>           if( dblh != dblw )
>>             if( dblh ) gfx_flags |= GFX_DBL_H; else
>>                        gfx_flags |= GFX_DBL_W;
>
>I never nest if's without adding braces, and never put the "then" or 
>"else" clause on the same line. Both can be confusing to read 
>(especially the former) and lead to bugs when maintaining the code.
>
>> The criticism I received is that the reader may not eaily
>> decide whether the author meant
>> 
>>                 if (dblh != dblw) {
>>                    if (dblh)
>>                       gfx_flags |= GFX_DBL_H;
>>                 } else {
>>                    gfx_flags |= GFX_DBL_W;
>>                 }
>
>Small digression:
>Not to trigger a flamewar here, I know this is a topic for potentially 
>heated debate here (coding style almost always is), but I personally 
>just hate the opening braces at the end of lines. This style has become 
>pervasive. I think it initially comes from the Kernighan & Richie style, 
>which granted were the authors of C, but we have to keep in mind that in 
>the 70's, screen estate was really at a premium, so it saved extra 
>lines.

Screen real estate is still scarce; the more of a function you
can fit on a single page, the better the development experience
is.   Braces on a line by themselves just waste vertical space.

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

#149839

On Friday, February 7, 2020 at 9:26:48 AM UTC-6, Scott Lurndal wrote:
> Guillaume <message@bottle.org> writes:
> >Small digression:
> >Not to trigger a flamewar here, I know this is a topic for potentially 
> >heated debate here (coding style almost always is), but I personally 
> >just hate the opening braces at the end of lines. This style has become 
> >pervasive. I think it initially comes from the Kernighan & Richie style, 
> >which granted were the authors of C, but we have to keep in mind that in 
> >the 70's, screen estate was really at a premium, so it saved extra 
> >lines.
> 
> Screen real estate is still scarce; the more of a function you
> can fit on a single page, the better the development experience
> is.   Braces on a line by themselves just waste vertical space.

Second!

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

#149918

On Friday, February 7, 2020 at 8:47:34 PM UTC-5, luser droog wrote:
> On Friday, February 7, 2020 at 9:26:48 AM UTC-6, Scott Lurndal wrote:
> > Guillaume <m...@bottle.org> writes:
> > >Small digression:
> > >Not to trigger a flamewar here, I know this is a topic for potentially 
> > >heated debate here (coding style almost always is), but I personally 
> > >just hate the opening braces at the end of lines. This style has become 
> > >pervasive. I think it initially comes from the Kernighan & Richie style, 
> > >which granted were the authors of C, but we have to keep in mind that in 
> > >the 70's, screen estate was really at a premium, so it saved extra 
> > >lines.
> > 
> > Screen real estate is still scarce; the more of a function you
> > can fit on a single page, the better the development experience
> > is.   Braces on a line by themselves just waste vertical space.
> 
> Second!

if (condition) {
  do_something();
  do_something_else(); }

No problems with that logic ;-)

Best regards,
John D.

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

#150051

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

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

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

csiph-web