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

Started byAnton Shepelev <anton.txt@gmail.com>
First post2020-01-31 23:46 +0300
Last post2020-02-29 03:30 -0800
Articles 20 on this page of 137 — 34 participants

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 1 of 7  [1] 2 3 4 5 6 7  Next page →

#149567 — Coding style for small if statements

FromAnton Shepelev <anton.txt@gmail.com>
Date2020-01-31 23:46 +0300
SubjectCoding style for small if statements
Message-ID<20200131234613.59047e037939ceb549b8e6d6@gmail.com>
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?

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

[toc] | [next] | [standalone]

#149568

FromAnton Shepelev <anton.txt@gmail.com>
Date2020-01-31 23:54 +0300
Message-ID<20200131235446.1eb54beabc491ad372460592@gmail.com>
In reply to#149567
I wrote:

> whereas in my option the indentation makes the perfectly
> clear while keeping it concise:

in my *opinion*
makes the *code* perfectly clear

> I do not consier ?: as redundant and unintuitive.

I do not *consider* ?: because I think it redundant and
unintuitive.

Sorry for more types than usual.  Perhaps they are due the
cold and fever I am having.

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

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

#149576

FromLes Cargill <lcargill99@comcast.com>
Date2020-01-31 19:13 -0600
Message-ID<r12j9m$oac$1@dont-email.me>
In reply to#149568
Anton Shepelev wrote:
> I wrote:
> 
>> whereas in my option the indentation makes the perfectly
>> clear while keeping it concise:
> 
> in my *opinion*
> makes the *code* perfectly clear
> 
>> I do not consier ?: as redundant and unintuitive.
> 
> I do not *consider* ?: because I think it redundant and
> unintuitive.
> 


I've slid into thinking in different terms these days. I prefer
the "? :" approach when done in a certain way.

I'd translate:


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

into
	const bool same     = (dblh==dblw);
	const bool use_h    = (dblh!=0);
	gfx_flags |= (same) ? 0 : ( use_h ) ? GFX_DBL_H : GFX_DBL_W : 0;

I'll even write a scope loop for both to prove them the same if I'm not
sure about the second formulation.

Why? Because there are three outcomes and they're all right there on one 
line. In English :

"If they are the same, then do nothing.
Else if dblh is nonzero, then use  GFX_DBL_H , else use  GFX_DBL_W."

It avoids all the formatting issues and sort of signals ( to me ) "I
scope looped this and checked the truth tables."

To wit:

#include <stdint.h>
#include <stdio.h>
#include <stdbool.h>

typedef enum
{
     GFX_DBL_H = 0x40,
     GFX_DBL_W = 0x80,
} a_type;

const int32_t first_way(const int32_t dblh,const int32_t dblw,int32_t 
gfx_flags)
{
     if ( dblh != dblw )
         if ( dblh ) gfx_flags |= GFX_DBL_H;
         else
             gfx_flags |= GFX_DBL_W;
     return gfx_flags;
}

const int32_t second_way(const int32_t dblh,const int32_t dblw,int32_t 
gfx_flags)
{
     const bool same     = (dblh==dblw);
     const bool use_h    = (dblh!=0);
     gfx_flags |= (same) ?  0 : ( use_h ) ? GFX_DBL_H : GFX_DBL_W  ;
     return gfx_flags;
}

int main(void)
{
     int32_t dblh        = 0;
     int32_t dblw        = 0;
     int32_t gfx_flags   = 0;

     const int32_t lim = 7;
     for (dblw=0; dblw<lim; dblw++)
     {
         for (dblh=0; dblh<lim; dblh++)
         {
             const int32_t a = first_way(dblh,dblw,gfx_flags);
             const int32_t b = first_way(dblh,dblw,gfx_flags);
             printf("dblh %5d dblw %5d gfx_flags %5X a %5X b 
%5X\n",dblh,dblw,gfx_flags,a,b);
         }
         printf("\n");
     }
     return 0;
}


Output:

dblh     0 dblw     0 gfx_flags     0 a     0 b     0
dblh     1 dblw     0 gfx_flags     0 a    40 b    40
dblh     2 dblw     0 gfx_flags     0 a    40 b    40
dblh     3 dblw     0 gfx_flags     0 a    40 b    40
dblh     4 dblw     0 gfx_flags     0 a    40 b    40
dblh     5 dblw     0 gfx_flags     0 a    40 b    40
dblh     6 dblw     0 gfx_flags     0 a    40 b    40

dblh     0 dblw     1 gfx_flags     0 a    80 b    80
dblh     1 dblw     1 gfx_flags     0 a     0 b     0
dblh     2 dblw     1 gfx_flags     0 a    40 b    40
dblh     3 dblw     1 gfx_flags     0 a    40 b    40
dblh     4 dblw     1 gfx_flags     0 a    40 b    40
dblh     5 dblw     1 gfx_flags     0 a    40 b    40
dblh     6 dblw     1 gfx_flags     0 a    40 b    40

dblh     0 dblw     2 gfx_flags     0 a    80 b    80
dblh     1 dblw     2 gfx_flags     0 a    40 b    40
dblh     2 dblw     2 gfx_flags     0 a     0 b     0
dblh     3 dblw     2 gfx_flags     0 a    40 b    40
dblh     4 dblw     2 gfx_flags     0 a    40 b    40
dblh     5 dblw     2 gfx_flags     0 a    40 b    40
dblh     6 dblw     2 gfx_flags     0 a    40 b    40

dblh     0 dblw     3 gfx_flags     0 a    80 b    80
dblh     1 dblw     3 gfx_flags     0 a    40 b    40
dblh     2 dblw     3 gfx_flags     0 a    40 b    40
dblh     3 dblw     3 gfx_flags     0 a     0 b     0
dblh     4 dblw     3 gfx_flags     0 a    40 b    40
dblh     5 dblw     3 gfx_flags     0 a    40 b    40
dblh     6 dblw     3 gfx_flags     0 a    40 b    40

dblh     0 dblw     4 gfx_flags     0 a    80 b    80
dblh     1 dblw     4 gfx_flags     0 a    40 b    40
dblh     2 dblw     4 gfx_flags     0 a    40 b    40
dblh     3 dblw     4 gfx_flags     0 a    40 b    40
dblh     4 dblw     4 gfx_flags     0 a     0 b     0
dblh     5 dblw     4 gfx_flags     0 a    40 b    40
dblh     6 dblw     4 gfx_flags     0 a    40 b    40

dblh     0 dblw     5 gfx_flags     0 a    80 b    80
dblh     1 dblw     5 gfx_flags     0 a    40 b    40
dblh     2 dblw     5 gfx_flags     0 a    40 b    40
dblh     3 dblw     5 gfx_flags     0 a    40 b    40
dblh     4 dblw     5 gfx_flags     0 a    40 b    40
dblh     5 dblw     5 gfx_flags     0 a     0 b     0
dblh     6 dblw     5 gfx_flags     0 a    40 b    40

dblh     0 dblw     6 gfx_flags     0 a    80 b    80
dblh     1 dblw     6 gfx_flags     0 a    40 b    40
dblh     2 dblw     6 gfx_flags     0 a    40 b    40
dblh     3 dblw     6 gfx_flags     0 a    40 b    40
dblh     4 dblw     6 gfx_flags     0 a    40 b    40
dblh     5 dblw     6 gfx_flags     0 a    40 b    40
dblh     6 dblw     6 gfx_flags     0 a     0 b     0


> Sorry for more types than usual.  Perhaps they are due the
> cold and fever I am having.
> 

-- 
Les Cargill

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

#150146

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2020-02-22 07:52 -0800
Message-ID<86r1ymd3h6.fsf@linuxsc.com>
In reply to#149568
Anton Shepelev <anton.txt@gmail.com> writes:

[combined with additional context from earlier post]

> I do not consider ?: because I think it 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.

The comments you give help explain your reaction.  I am also a
programmer and mathematician, and I never had any such reaction.
After all, there are plenty of cases in math books where something
is defined as "<something> if <condition> and <something-else>
otherwise."  Besides which, the ?: operator in C is a new notation,
so "intuition" about it shouldn't carry much weight.  In any case,
whatever the reasons for your original reaction, I recommend
overcoming that initial reaction and embracing the use of ?: in
situations like the context of the earlier discussion.  I think you
will find the ?: operator is quite useful in writing programs more
concisely and understandably, even if in some technical sense it is
"unnecessary" because of if()/else.  Good notation is a powerful
tool.  The ?: operator is not a substitute for if()/else, but a
related construction in a functional thought mode, as opposed to
the more usual (for C) imperative thought mode.  Programming in
C should not be limited to an imperative thought mode;  there
are plenty of circumstances where an imperative thought mode is the
way to go, but there are also plenty of circumstances where an
functional thought mode is the way to go, and ?: can help with
those.

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

#149569

FromAnton Shepelev <anton.txt@gmail.com>
Date2020-02-01 00:06 +0300
Message-ID<20200201000607.f37490a1fb31317d2d9057b9@gmail.com>
In reply to#149567
I wrote:

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

Improved version:

              if( dblh != dblw )
                if( dblh ) gfx_flags |= GFX_DBL_H;
                else       gfx_flags |= GFX_DBL_W;
-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#150339

Frommathog <dmathog@gmail.com>
Date2020-02-28 10:20 -0800
Message-ID<r3bllr$nq8$1@dont-email.me>
In reply to#149569
Anton Shepelev wrote:
> I wrote:
> 
>>           if( dblh != dblw )
>>             if( dblh ) gfx_flags |= GFX_DBL_H; else
>>                        gfx_flags |= GFX_DBL_W;
> 
> Improved version:
> 
>                if( dblh != dblw )
>                  if( dblh ) gfx_flags |= GFX_DBL_H;
>                  else       gfx_flags |= GFX_DBL_W;
> 

My goal is to NEVER use an if, else, or else if statement without {}. 
It is just way too easy to misread the implicit forms or to accidentally 
brake the logic while reformatting some code.  Ditto for "for" and other 
formats where the braces are optional.  So...

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

also for the single line cases:

    if( test ){ fprintf(stderr,"some error message\n"); }

People have all sorts of opinions about the proper stylistic formatting 
of such things, ie:

    if(something){ dothis; }
    if (something) { dothis; }
    if ( something ) { dothis; }
    if ( something ) {
      dothis;
    }
    etc.

I don't think any of those variations matter nearly as much as they are 
just white space, whereas the brackets are not.

I am also a fan of the ternary expression in a single line

    valFinal = (test ? valT : valF);

As opposed to the corresponding multiline if/else.  Especially if the 
Lvalue is to be declared at that point.  However ternary expressions 
which will not fit on one line or are nested are to my eye more 
difficult to read than are the equivalent if/else constructs.

Regards,

David Mathog

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

#149571

FromLew Pitcher <lew.pitcher@digitalfreehold.ca>
Date2020-01-31 16:28 -0500
Message-ID<r1265b$i60$1@dont-email.me>
In reply to#149567
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:
> 
>          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.

While I find the above code readable, my personal preference (established 
through years of both original and maintenance coding) would be to write

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

My rationale for this form consists of:
* use whitespace to separate the "if" from the condition, so as to
  visually distinguish it from a function call
* separate the components of the condition with whitespace to provide the
  reader with visual cues that facilitate code comprehension  
* give the outer "if" a compound statement, to permit
  * clarity of comprehension to the reader of this code fragment, and
  * a space to expand (if and when required) the actions performed
    for the "true" side of the statement
* align the opening and closing braces of the compound statement
  with the "if" to provide a visual cue to the reader that the
  compound statement "belongs" with the "if"
* on the inner "if" statement, align the  "else" with the "if" to
  provide a visual cue to the reader that the "else" belongs with
  /that/ "if"
* consistant indentation for depth of logic (without exposition,
  I don't know how to express this better)

And, yes, I didn't apply all these equally; I expect the reader to be 
knowledgable enough about the craft to read the code. Ghu knows I've 
encountered my share of obscure and oblique code, written by programmers 
long departed from the craft, and been expected to understand it well enough 
to make changes (or rewrite if necessary) under (sometimes severe) time 
constraints.

> 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;
>                }

A fair concern, I guess (given my comments above).

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

Yes, your indentation shows your intention. But, the reader can't depend on 
that. 

> I do not consier ?: as redundant and unintuitive.

Neither do I. But, then again, the audience for /my/ source code is very 
limited these days (even more so than it was before I retired). While we 
cannot anticipate the skills of our successors, it is often prudent to write 
code "defensively", to make it clear to those who come after. Let the 
compiler optimize the code, if that's the concern.

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

Agreed.

> What are your opinions?

See above.


-- 
Lew Pitcher
"In Skills, We Trust"

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

#149595

Fromdonalhambra@gmail.com
Date2020-02-01 04:55 -0800
Message-ID<330599a2-5815-40a7-af37-ac93b203b843@googlegroups.com>
In reply to#149567
On Friday, January 31, 2020 at 3:46:22 PM UTC-5, 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:
> 
>          if( dblh != dblw )
>            if( dblh ) gfx_flags |= GFX_DBL_H; else
>                       gfx_flags |= GFX_DBL_W;
> 

           if (dblh != dblw)
               gfx_flags = (dblh) ? GFX_DBL_H : GFX_DBL_W;

-Don

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

#149612

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2020-02-01 17:16 +0000
Message-ID<87mua2xm79.fsf@bsb.me.uk>
In reply to#149595
donalhambra@gmail.com writes:

> On Friday, January 31, 2020 at 3:46:22 PM UTC-5, 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:
>> 
>>          if( dblh != dblw )
>>            if( dblh ) gfx_flags |= GFX_DBL_H; else
>>                       gfx_flags |= GFX_DBL_W;
>> 
>
>            if (dblh != dblw)
>                gfx_flags = (dblh) ? GFX_DBL_H : GFX_DBL_W;

s/=/|=/ but, yes, that's probably what I'd write (without the
parentheses).

One could get "cute":

  gfx_flags |= (dblh != dblw) * (dblh ? GFX_DBL_H : GFX_DBL_W);

but I don't think I like that.

-- 
Ben.

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

#149644

Fromluser droog <luser.droog@gmail.com>
Date2020-02-02 11:03 -0800
Message-ID<6c9c068f-6f95-4ba5-a782-57e5d66ff78a@googlegroups.com>
In reply to#149612
On Saturday, February 1, 2020 at 11:16:17 AM UTC-6, Ben Bacarisse wrote:
> donalhambra@gmail.com writes:
> 
> > On Friday, January 31, 2020 at 3:46:22 PM UTC-5, 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:
> >> 
> >>          if( dblh != dblw )
> >>            if( dblh ) gfx_flags |= GFX_DBL_H; else
> >>                       gfx_flags |= GFX_DBL_W;
> >> 
> >
> >            if (dblh != dblw)
> >                gfx_flags = (dblh) ? GFX_DBL_H : GFX_DBL_W;
> 
> s/=/|=/ but, yes, that's probably what I'd write (without the
> parentheses).
> 
> One could get "cute":
> 
>   gfx_flags |= (dblh != dblw) * (dblh ? GFX_DBL_H : GFX_DBL_W);
> 
> but I don't think I like that.
> 

I like it. How about going further?

  gfx_flags |= (dblh ^ dblw) * (dblh ? GFX_DBL_H : GFX_DBL_W);

I suppose this makes more assumptions about the values of dblw and dblh.
They must be the same non-zero value or zero.

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

#149661

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2020-02-03 02:20 +0000
Message-ID<871rrcxvga.fsf@bsb.me.uk>
In reply to#149644
luser droog <luser.droog@gmail.com> writes:

> On Saturday, February 1, 2020 at 11:16:17 AM UTC-6, Ben Bacarisse wrote:
>> donalhambra@gmail.com writes:
>> 
>> > On Friday, January 31, 2020 at 3:46:22 PM UTC-5, 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:
>> >> 
>> >>          if( dblh != dblw )
>> >>            if( dblh ) gfx_flags |= GFX_DBL_H; else
>> >>                       gfx_flags |= GFX_DBL_W;
>> >> 
>> >
>> >            if (dblh != dblw)
>> >                gfx_flags = (dblh) ? GFX_DBL_H : GFX_DBL_W;
>> 
>> s/=/|=/ but, yes, that's probably what I'd write (without the
>> parentheses).
>> 
>> One could get "cute":
>> 
>>   gfx_flags |= (dblh != dblw) * (dblh ? GFX_DBL_H : GFX_DBL_W);
>> 
>> but I don't think I like that.
>> 
>
> I like it. How about going further?
>
>   gfx_flags |= (dblh ^ dblw) * (dblh ? GFX_DBL_H : GFX_DBL_W);
>
> I suppose this makes more assumptions about the values of dblw and dblh.
> They must be the same non-zero value or zero.

Given the context (and the names), I would not even assume that they are
of integer type.

-- 
Ben.

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

#149662

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-02-03 05:17 +0100
Message-ID<r186se$eec$1@news.albasani.net>
In reply to#149612
> One could get "cute":
>    gfx_flags |= (dblh != dblw) * (dblh ? GFX_DBL_H : GFX_DBL_W);

That's obfuscation.

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

#149664

Fromchad <cdalten@gmail.com>
Date2020-02-03 04:07 -0800
Message-ID<d824b603-bcff-4872-9b20-72a82a9a5452@googlegroups.com>
In reply to#149662
I forgot the argument. But a long time ago I had a former college professor who told me that using "?" didn't always yield the same results. It had something to do with turing completeness.

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

#149692

Fromluser droog <luser.droog@gmail.com>
Date2020-02-03 12:59 -0800
Message-ID<a84bdf5d-6735-4573-bf91-6b734ed16722@googlegroups.com>
In reply to#149664
On Monday, February 3, 2020 at 6:07:43 AM UTC-6, chad wrote:
> I forgot the argument. But a long time ago I had a former college professor who told me that using "?" didn't always yield the same results. It had something to do with turing completeness.

That's stupid.

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

#149708

Fromchad <cdalten@gmail.com>
Date2020-02-03 20:54 -0800
Message-ID<982e9b41-0faa-435a-ac19-b3e195ccd839@googlegroups.com>
In reply to#149692
On Monday, February 3, 2020 at 12:59:48 PM UTC-8, luser droog wrote:
> On Monday, February 3, 2020 at 6:07:43 AM UTC-6, chad wrote:
> > I forgot the argument. But a long time ago I had a former college professor who told me that using "?" didn't always yield the same results. It had something to do with turing completeness.
> 
> That's stupid.

Pull my finger.

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

#149609

Fromnobody@example.org (Scott)
Date2020-02-01 16:44 +0000
Message-ID<5e35a8f6.142826547@core>
In reply to#149567
On Fri, 31 Jan 2020 23:46:13 +0300, Anton Shepelev
<anton.txt@gmail.com> 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:
>
>         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

To me it is perfectly clear, and it's unambiguous to the compiler as
well. But we've both seen a *lot* of code.

Some newer compilers appear to have some awareness of indentation in
conditional statements without {brace delimiters}, as a way to suggest
that the appearance may not align with the actual semantics. I think
that's a good idea.

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

#149631

Fromalready5chosen@yahoo.com
Date2020-02-02 04:40 -0800
Message-ID<407eb553-8696-4118-b87d-ddb81885010c@googlegroups.com>
In reply to#149567
On Friday, January 31, 2020 at 10:46:22 PM UTC+2, 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:
> 
>          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?
> 
> -- 
> ()  ascii ribbon campaign -- against html e-mail
> /\  http://preview.tinyurl.com/qcy6mjc [archived]

I agree with the criticism and  in general prefer the 3rd variant.
In general, that is.
In this specific case the 3rd variant violates DRY, so I'd write it in DRY-compliant way:

if (dblh != dblw )
  gfx_flags |= (dblh != 0) ? GFX_DBL_H : GFX_DBL_W;

Yes, with extra () and extra != 0

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

#149634

FromDavid Brown <david.brown@hesbynett.no>
Date2020-02-02 15:47 +0100
Message-ID<r16ne2$lup$1@dont-email.me>
In reply to#149567
On 31/01/2020 21:46, 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:
> 
>           if( dblh != dblw )
>             if( dblh ) gfx_flags |= GFX_DBL_H; else
>                        gfx_flags |= GFX_DBL_W;
> 

I like to keep things simple and consistent.  If I have indentation, I 
have brackets.  If I have "else", I have brackets.

	if (dblh != dblw) {
	    if (dblh) {
	        gfx_flags |= GFX_DBL_H;
	    } else {
	        gfx_flags |= GFX_BDL_W;
	    }
	}


Sometimes I might have:

	if (dblh != dblw) {
	    gfx_flags |= dblh ? GFX_DBL_H : GFX_DBL_W;
	}


Usually, however, I prefer the more expanded style.  It makes it 
blindingly obvious what is going on - even the most inexperienced reader 
can see it straight away.  The chances of a mismatch between what the 
code appears to do, and what it /does/ do, are minimal.  You can space 
to tag on comments if you want, or to add debug code (logging printf's, 
for example), breakpoints when debugging, or more code - without having 
to change the structure or worry about what the if's and else's apply to.

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

#149702

FromJorgen Grahn <grahn+nntp@snipabacken.se>
Date2020-02-03 23:56 +0000
Message-ID<slrnr3hcp8.km3.grahn+nntp@frailea.sa.invalid>
In reply to#149567
On Fri, 2020-01-31, 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:
>
>          if( dblh != dblw )
>            if( dblh ) gfx_flags |= GFX_DBL_H; else
>                       gfx_flags |= GFX_DBL_W;
...
> What are your opinions?

My opinion is simple: I like and use a short, simple, one-line if:

    if (dblh) gfx_flags |= GFX_DBL_H;

but for anything more more complex, I want curly brackets
and proper indentation.

I can read other styles, but they make me suspicious.

/Jorgen

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

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

#150046

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2020-02-16 05:34 -0800
Message-ID<86sgjafygj.fsf@linuxsc.com>
In reply to#149702
Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Fri, 2020-01-31, 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:
>>
>>          if( dblh != dblw )
>>            if( dblh ) gfx_flags |= GFX_DBL_H; else
>>                       gfx_flags |= GFX_DBL_W;
>
> ...
>
>> What are your opinions?
>
> My opinion is simple:  I like and use a short, simple, one-line if:
>
>     if (dblh) gfx_flags |= GFX_DBL_H;

I am curious.  Would your criteria for shortness and simpleness
admit the whole ball of wax here as a single one-line statement:

    if( dblh != dblw )  gfx_flags |= dblx ? GFX_DBL_H : GFX_DBL_H;

My own criteria for admitting a one-line 'if' include the question
"Does this make sense being read as a single line?", which probably
gets a Yes answer in this case.  (The "probably" arises because
there may be other not-yet-known context that would bear on the
question.)

> but for anything more more complex, I want curly brackets
> and proper indentation.

Yeah.  I might be willing to make an exception in some unusual
circumstances, but circumstances sufficiently unusual are few
and far between.

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

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

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

csiph-web