Re: operator precedence

From	Ben <ben.usenet@bsb.me.uk>
Newsgroups	comp.lang.c
Subject	Re: operator precedence
Date	2022-04-26 15:58 +0100
Organization	A noiseless patient Spider
Message-ID	<87v8uvq4bv.fsf@bsb.me.uk> (permalink)
References	(1 earlier) <t2v61c$ej9$1@gioia.aioe.org> <86v8ux58zx.fsf@linuxsc.com> <t46qkv$ull$1@dont-email.me> <87ee1kudbm.fsf@bsb.me.uk> <t48s6g$4ir$1@dont-email.me>

Show all headers | View raw

David Brown <david.brown@hesbynett.no> writes:

> On 25/04/2022 22:18, Ben wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> 
>>> On 25/04/2022 20:10, Tim Rentsch wrote:
>>>> Guillaume <message@bottle.org> writes:
>>>>
>>>>> Le 08/04/2022 at 14:00, Stefan Ram a ecrit:
>>>>>
>>>>>>     Recently, I wrote:
>>>>>>
>>>>>> board & 1 << row * COLS + col
>>>>>
>>>>> If I saw this coming from someone in my team, I would probably fire them. =)
>>>>>
>>>>> I'm not even sure this is correct from what you really intended.  But
>>>>> even if it is, there's a rule in programming, IMO, that's above the
>>>>> programming language's grammar:  readability for us humans.
>>>>>
>>>>> Code we write is meant for humans, not machines.  That's something
>>>>> people forget way too often.  That's why we write using higher-level
>>>>> languages, not assembly or even machine code.  Or, look at the
>>>>> obfuscated C contest and such.  This is proper C from a language
>>>>> standpoint, but nothing you'd want to deal with.
>>>>>
>>>>> The readability rule that applies here is, if you need more than a few
>>>>> seconds figuring out what a given statement exactly does, and may have
>>>>> to even open the C standard to make sure, then it's badly
>>>>> written.  Rewrite it.
>>>>
>>>> Human readability can be improved as follows:
>>>>
>>>>      board  &  1 << row*COLS+col
>>>
>>> If I saw that coming from someone in my team, I would treat it as worse
>>> than the original.  Anyone who thinks mixing inconsistent spacing into
>>> this improves things, has completely missed the point (unless they are
>>> using some programming language that considers the number of spaces in
>>> an expression as significant).
>> You presumably think that there is only one notion of consistent
>> spacing, but spacing to show operator binding is consistent
>> with... well, with doing so.  I've seen it quite a lot.  I do it myself
>> even when it hardly matters:
>>     int mid = (low + high)/2;
>> looks better, to me, with the /2 glued right up to the ()s.
>
> I tend to stick to consistent spacing, but I am always open to bending
> such rules if it results in clearer code.  (And I also understand that
> different people have different spacing rules that they apply at least
> reasonably consistently.)

I think mean you prefer the a fixed number of spaces (one) around each
binary operator and, guessing, none between unary operators and
operands.

> But I think it is rare that unusual, inconsistent or extra spaces are
> going to make an expression significantly clearer or easier to parse
> (for the human reader).  You might feel that skipping the spaces on
> your "/2" example makes the line look nicer - and maybe it does,
> perhaps depending on fonts and other visual details.  However, I don't
> think you'd claim that it makes the functional effect of the statement
> more immediately obvious to the reader, or reduces the risk of it
> being misinterpreted.

Indeed I would not.  As you know, I am not that interested in surface
syntax.  I have preferences, but can't get as het up about it as some
people seem to.

>>> For code clarity, it is important that the compiler and human readers
>>> agree on what the code means, that the human can easily see what it
>>> means, and easily see that the compiler will view it the same way.
>> The trouble with these sort of overly general platitudes is they don't
>> help people like me (now thankfully out of the game) to know what you
>> think needs to be clarified.  How would you parenthesise the above, and
>> why?
>
> I have intentionally been a bit vague on the details, because I don't
> think there is one correct set of rules that apply to all people, all
> projects, all types of coding task.
>
> I would prefer :
>
> 	board & 1 << (rows * COLS + col)

Ta.  That tells me what priorities you think people may confuse.  If I
had to add a pair, I'd have gone with

  board & (1 << rows * COLS + col)

since I would assume that a lot of C programmers know some C++ and
therefore know that one never has to parenthesise basic arithmetic in
C++ output expressions.

> I am not sure I would go as far as MISRA would like :
>
> 	board & (1 << (rows * COLS + col))

They leave it vague.  Applying the rule strictly, it would require

 	board & (1 << ((rows * COLS) + col))

> There's no single one "correct" or "best" way to write this or any
> other code.

I know.  I just like to see what other people prefer.

-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: operator precedence Guillaume <message@bottle.org> - 2022-04-10 20:01 +0200
  Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-10 20:34 +0100
    Re: operator precedence Guillaume <message@bottle.org> - 2022-04-11 20:52 +0200
      Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-11 21:27 +0100
        Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-14 13:38 +0200
          Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-14 14:07 +0100
            Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-18 14:00 +0200
        Re: operator precedence Guillaume <message@bottle.org> - 2022-04-15 19:28 +0200
          Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-15 19:25 +0100
            Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-18 14:12 +0200
              Re: operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-18 16:38 +0000
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-18 19:20 +0200
                Re: operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-19 17:40 +0000
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-19 22:41 +0200
              Re: operator precedence James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-18 23:08 -0400
                Re: operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 08:40 -0700
                Re: operator precedence "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-25 10:35 -0700
  Re: operator precedence Vir Campestris <vir.campestris@invalid.invalid> - 2022-04-10 21:51 +0100
  Re: operator precedence Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-11 11:35 +0200
  Re: operator precedence gazelle@shell.xmission.com (Kenny McCormack) - 2022-04-11 13:53 +0000
  Re: operator precedence Guillaume <message@bottle.org> - 2022-04-11 20:36 +0200
  Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-14 13:14 +0200
  Re: operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 11:10 -0700
    Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-25 20:52 +0200
      Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-25 21:18 +0100
        Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-26 15:30 +0200
          Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-26 15:58 +0100
            Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-26 21:19 +0200
              Re: operator precedence Sams Lara <samlara622@gmail.com> - 2022-04-27 02:15 +0100
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-27 09:13 +0200
                Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-27 19:43 +0100
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-28 10:09 +0200
                Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-28 10:44 +0100
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-28 11:59 +0200
                Re: operator precedence Giovanni <lsodgf0@home.net.it> - 2022-04-28 12:29 +0200
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-28 12:56 +0200
                Re: operator precedence Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-28 04:17 -0700
                Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-28 12:24 +0100
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-28 14:28 +0200
                Re: operator precedence Dan Purgert <dan@djph.net> - 2022-04-28 14:00 +0000
                Re: operator precedence Dan Purgert <dan@djph.net> - 2022-04-28 14:38 +0000
                Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-28 20:36 +0100
                Re: operator precedence Richard Harnden <richard.nospam@gmail.com> - 2022-04-28 21:22 +0100
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-29 09:43 +0200
                Re: operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-28 20:51 +0000
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-29 10:04 +0200
                Re: operator precedence Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-29 03:01 -0700
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-29 15:02 +0200
                Re: operator precedence James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-29 10:48 -0400
                Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-29 17:29 +0200
            Re: operator precedence bart c <bart4858@gmail.com> - 2022-04-26 14:30 -0700
              Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-27 00:00 +0100
              Re: operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-27 09:46 +0200
          Re: operator precedence Öö Tiib <ootiib@hot.ee> - 2022-04-27 00:10 -0700
    Re: operator precedence scott@slp53.sl.home (Scott Lurndal) - 2022-04-25 19:02 +0000
      Re: operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-25 21:38 +0100
        Re: operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 22:22 -0700

csiph-web