Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #165615
| From | Guillaume <message@bottle.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: operator precedence |
| Date | 2022-04-11 20:52 +0200 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <t31tda$1ohm$1@gioia.aioe.org> (permalink) |
| References | <thought-20220408125437@ram.dialup.fu-berlin.de> <t2v61c$ej9$1@gioia.aioe.org> <87bkx868cm.fsf@bsb.me.uk> |
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. >> 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. 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. 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. 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.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
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