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 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]

#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]

#150907

On Monday, 30 March 2020 14:04:58 UTC+1, Kenny McCormack  wrote:
> 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.
> 
>
We're on corona virus lockdown. So the computer is the only connection
to the outside world.

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

#151022

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

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

I sometimes write controlled statements (of if(), for(), etc), on
the same line as the if(), etc.  When I do this I do not use
braces unless they are necessary for some other reason.

When I write a controlled statement on a subsequent line, even if
it is only a single (non-block) statement, I always use braces.

Do you always use braces for controlled statements not on the
same line as the controlling phrase (if(), etc)?

If you do, doesn't the if() or for(), etc, vertically aligned
with the closing brace, stand out to show the range/pairing of
each group?  I don't see how putting in an additional line with
just an open brace adds any useful information.  (Please note
that I am not saying there isn't any, just that I don't see
how there is.)


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

First I assume the alternative you want me to consider for this
question is not this

    if(...){
      something;
    } next statement...

but this

    if(...){
      something; }

(with the understanding that horizontal white space is not part
of the question).  Incidentally this latter form is sometimes
called "Lisp style".  Some C programmers do use Lisp-style
placement of closing braces (even though I myself do not).

Surely everyone knows this, but for completeness, K&R style is
this

    if(...){
      something;
    }

with the closing brace lined up under the 'i' of 'if' or the 'f'
of 'for', etc.

I think K&R-style closing brace placement is a better choice
than, eg, Lisp-style placement, because studies have found that
defect rates are lowest for the placement of closing braces where
K&R style puts them.  (I don't know of any corresponding study
for the placement of open braces.)  This result matches my
personal experience, although of course that experience is
evaluated subjectively rather than trying to do some sort of
objective measurement.

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

#150071

Guillaume <message@bottle.org> writes:

> Le 31/01/2020 at 21:46, Anton Shepelev a ecrit:
>
>> [...] [example providing context next:]
>>
>>                 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.  These days, it's not really justified anymore and
> it just makes it look like block delimiters are an annoyance rather
> than a feature - I for one just don't agree with this point.  And I
> like to keep my things aligned.  End of digression anyway - there
> really seems to be two camps there with pretty aggressive positions.

I don't want to take part in any flamewar, but I would like to
ask:  Can you say why you prefer open braces placed elsewhere
beyond just that you don't like them there?  I have asked about
this (that is, putting open braces on different lines) several
times in the past and the only answers I've gotten seem to me to
be circular.  So I am interested to hear if you can explain your
reaction or reasons further.

Incidentally, the K&R bracing style didn't become pervasive, it
has always been pervasive since the early days of C.  And I am
pretty sure it wasn't because of small screens that people chose
this way of writing.  I know it wasn't for me, and I've been
programming since the days of small screens (and in fact even
before that).

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

#149905

On Fri, 31 Jan 2020 23:46:13 +0300, Anton Shepelev wrote:

> 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:
> 
> [Snip]
>
> What are your opinions?

	Here is mine: are you sure that you want to stick your hand in 
that wasps' nest? When it comes to coding styles, every has their own, 
and everybody is convinced that theirs is the right one, and that the 
others are crazy/delusional for believing the same about their own.

	Try something simpler, less headache-inducing - like e.g. herding 
cats.

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

#149977

Sorry, but the whole discussion is pure idiocy. If you program in
a team use the conventions of the team and otherwise use your own.

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

#150091

Anton Shepelev <anton.txt@gmail.com> writes:

> 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;
>
> If the graphical mode of the DOS application is a double-
> with mode or a double-height mode, but not both, the
> function adds the corresponding flag to the gfx_flags set.
> 320x400, for example, is a double-height mode.

Downthread you give this

> Improved version:
> 
>          if( dblh != dblw )
>            if( dblh ) gfx_flags |= GFX_DBL_H;
>            else       gfx_flags |= GFX_DBL_W;

I agree the improved version is better than the original.  The
'else' at the end of the if line is peculiar;  I don't remember
seeing that in C code before.  Putting the else under the if
is more usual, and definitely better.

The if/else with the controlled assignments on the same lines as
the if and the else is good (and IMO better than writing these
assignments on separate lines, either with braces or without).
Writing the controlled assignments on the same lines as if and
else makes it easier to see the parallel construction of the
two controlled statements.

With regard to the outer 'if( dblh != dblw )', my own pattern
would use braces to the controlled (and indented) if/else.
This practice applies generally to if, else, do, while, for
(and also switch, though that almost never comes up):  either
a single statement on the same line, with no braces, or use
braces and indent for controlled statement(s) on subsequent
lines, regardless of whether the controlled block is a single
statement or multiple statements.

(The question of where the braces should go is a heated topic
which I defer for now, possibly to return to it later.)

Having said that, if someone wanted to write this example
without using braces, I would suggest and recommend greater
indentation for the controlled if/else statement:

        if( dblh != dblw )
            if( dblh ) gfx_flags |= GFX_DBL_H;
            else       gfx_flags |= GFX_DBL_W;

or even this:

        if( dblh != dblw )
                if( dblh ) gfx_flags |= GFX_DBL_H;
                else       gfx_flags |= GFX_DBL_W;

Especially for the second writing, there should be little doubt
as to what meaning the writer intended.


> 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;
>                }
>
> or
>
>                if (dblh != dblw) {
>                   if (dblh)
>                      gfx_flags |= GFX_DBL_H;
>                   else
>                      gfx_flags |= GFX_DBL_W;
>                }

I am just slightly sympathetic to this criticism.  There isn't
any question how the C language parses the original statement,
but it's easy to imagine that the writer somehow missed a space
or two and may have wanted to express a different meaning.  If
you try showing the revised versions with more indentation, what
does your critic say?  Is there just as much doubt for the
version with eight spaces of indentation?  I'm curious to hear
what they would say.

> In addition to that, GCC emits a warning about a dangling
> `else', whereas in my option the indentation makes the
> perfectly clear while keeping it concise:  the outer test of
> dblh != dblw acts upon the inner if-else operator as a
> whole.

I don't completely disagree, although I repeat my suggestion for
greater indentation.  I believe though that using braces on the
outer if is the more common practice.  If we add to that the
observation that GCC gives a warning, I think that's a pretty
strong indicator that using braces on the outer if is a better
choice here.

> I do not consier ?: as redundant and unintuitive.  My friend,
> a talented programmer and mathematician, initially thought
> that the second argument was used in case the first was false,
> because of the ordering of truth values in ascending order.
> Nothing in the syntax hints at the implied analogy with the
> if-then-else statement.

I defer comments (if any) on this question to a subsequent posting.

> What are your opinions?

I thought it would be better to offer relatively more in the way
of suggestions and observations, and relatively less in the way
of my own opinions, and that is what I have tried to do above.

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

#150352

W dniu piątek, 31 stycznia 2020 21:46:22 UTC+1 użytkownik Anton Shepelev napisał:
> 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;
> 
> If the graphical mode of the DOS application is a double-
> with mode or a double-height mode, but not both, the
> function adds the corresponding flag to the gfx_flags set.
> 320x400, for example, is a double-height mode.
> 
> 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;
>                }
> 
> or
> 
>                if (dblh != dblw) {
>                   if (dblh)
>                      gfx_flags |= GFX_DBL_H;
>                   else
>                      gfx_flags |= GFX_DBL_W;
>                }
> 
> In addition to that, GCC emits a warning about a dangling
> `else', whereas in my option the indentation makes the
> perfectly clear while keeping it concise: the outer test of
> dblh != dblw acts upon the inner if-else operator as a
> whole.
> 
> I do not consier ?: as redundant and unintuitive. My friend,
> a talented programmer and mathematician, initially thought
> that the second argument was used in case the first was false,
> because of the ordering of truth values in ascending order.
> Nothing in the syntax hints at the implied analogy with the
> if-then-else statement.
> 
> What are your opinions?
> 
i got no answer to this question but i recalled my previous atempts of make some 
ultrashort form (skin) of c, for instance to be able to writing most compact programs in c in a line or few lines of that c

(i name that thing as 'tiny c' sometimes)
(i also wanted it to be shorter than present c etc)

it is really hard thing as its really hard to get something enough good, 
(and even if you will find something ok it still doesnt mean it is that thing)
hovever i remembered i invented some 
tiny syntax for swich and that it was based on @ character

then i tried to remember what it damn was as i partially forget and couldnt find note on it (even when doing over 1 hour search on old notes, so for me it is another hint to post such things on usenet to not be totally forgotten ;c) finally today i found it,

(the form is based on what i was writing on this enum-like error passing 

a -1-> p()
  -2-> n()

(which is like natural switch) so this tiny c swich form is

a @1 skls
  @2 skjlksj

x @1 @2 foo() @3 boo()

things like that

i note it as its tiny interesting especially this @ (at) sign naturaly fits to work as 'case' sign

(im still not saying this is optimal but its worth to leave a notice)

[toc] | [prev] | [standalone]

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

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

csiph-web