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


Groups > comp.lang.c > #165617

Re: operator precedence

From Ben <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: operator precedence
Date 2022-04-11 21:27 +0100
Organization A noiseless patient Spider
Message-ID <878rsb4b8g.fsf@bsb.me.uk> (permalink)
References <thought-20220408125437@ram.dialup.fu-berlin.de> <t2v61c$ej9$1@gioia.aioe.org> <87bkx868cm.fsf@bsb.me.uk> <t31tda$1ohm$1@gioia.aioe.org>

Show all headers | View raw


Guillaume <message@bottle.org> writes:

> Le 10/04/2022 à 21:34, Ben a écrit :
>> Guillaume <message@bottle.org> writes:
>> 
>>> Le 08/04/2022 à 14:00, Stefan Ram a écrit :
>>>>     Recently, I wrote:
>>>> board & 1 << row * COLS + col
>>>
>>> If I saw this coming from someone in my team, I would probably fire
>>> them. =)
>> Why is this such a common trope?  I doubt any country has such poor
>> employment protection that anyone could be fired for such a thing so I
>> assume it's just a rhetorical device to say "I really care about this
>> issue", but surely there are other ways to do that without being so
>> Donal^H^H^H^H Alan Sugar about it.
>
> Come on. I thought the smiley would convey the idea that it was
> tongue-in-cheek, but apparently not. So yeah for those taking
> everything literally, this was just a humorous way of showing a strong
> disagreement.

OK.  My news client turns emoticons into smilies but it does not know
about =) so I missed it.  In fact I've never seen =) before.

The way people use happy faces (I think that's what =) is) these days, I
would use ;) to suggest I'm not serious.  Otherwise it could mean you'd
fire them and smile all the way to HR with their P45!

>>> 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.
>> The trouble with this (since I don't think you literally mean "you"
>> here) is who is the typical reader?  Do you aim for the lowest common
>> denominator, or something in the middle?  Does is vary by team?  If it's
>> a C compiler project, might you assume a higher standard of
>> comprehension?
>
> Readability, and trying to avoid hard-to-spot errors goes beyond being
> skilled and knowing grammars by heart. It's not a matter of being good
> or bad. For insance, indentation and whitespace are basically useless
> in C, but they help readability quite a bit, even if you are an expert
> in the language.

Of course.  I didn't really want to open up the discussion too wide, so
I was trying to ask only about those elements that related to what the
reader can be expected to know.

> Regarding operator precedence, this is exactly covered by rule 12.1 of
> MISRA-C:2012. "Limited dependence should be placed on operator
> precedence rules in expressions" It describes with examples what is
> what is not compliant.  While a number of MISRA-C rules can look "too
> much" to many, including myself, I think that would be a good start
> here regarding this issue.

I shall have to remain in the dark then about what you consider a good
start because the quote "Limited dependence should be placed on operator
precedence rules in expressions" I think MISRA costs money.

> And whether you consider those guidelines in general to "aim for the
> lowest common denominator" is debatable. The fact one may be convinced
> to know better than those guidelines is also highly questionable.

There are other considerations.  Sometimes respecting your team's
ability to get it right without a thick tome of guidelines works
better.

> Similar rules can be seen in other similar standards/coding
> guidelines. Apparently no one that answered here have ever ahd to deal
> with any of those, otherwise what I said would probably sound pretty
> obvious.

I have.  I hated it.  I looked for another job where I was trusted to
write readable code.

-- 
Ben.

Back to comp.lang.c | Previous | NextPrevious 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