Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #399456 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-05-27 19:53 +0200 |
| Last post | 2026-05-30 11:18 +0200 |
| Articles | 20 on this page of 165 — 17 participants |
Back to article view | Back to comp.lang.c
this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 19:53 +0200
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-27 20:15 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-27 18:49 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 04:53 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 02:35 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:32 +0000
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 20:07 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-28 11:48 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-28 09:18 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 04:57 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:35 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:52 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 05:20 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-29 13:22 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 15:16 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 13:52 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-30 14:40 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 16:36 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 15:48 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:14 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-31 13:25 -0500
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:14 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 15:22 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 03:49 +0000
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-28 12:47 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 09:56 +0200
Re: this girl calls c ugly "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-05-29 11:00 -0700
Re: this girl calls c ugly fir <profesor.fir@gmail.com> - 2026-05-28 17:12 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-28 14:07 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-28 23:54 +0000
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 10:02 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 12:19 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 14:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 14:22 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 17:15 +0200
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-05-29 15:59 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:12 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:48 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:09 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:00 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:14 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:09 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 17:05 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:34 +0200
Re: this girl calls c ugly tTh <tth@none.invalid> - 2026-05-29 19:29 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 18:53 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 12:28 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 20:49 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:03 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 13:56 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 22:54 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 15:52 -0700
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 20:31 -0400
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 02:03 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-29 19:02 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:12 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-30 12:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 13:56 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 16:43 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-31 03:37 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-30 19:53 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:16 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:47 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 12:55 +0200
Re: this girl calls c ugly Richard Harnden <richard.nospam@gmail.invalid> - 2026-05-31 09:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 11:49 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 11:10 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:18 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:24 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 17:35 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 12:46 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 22:24 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 18:26 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:28 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 15:54 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 08:39 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:33 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:48 +0200
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-02 06:37 -0400
Constants and undefined behavior Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 05:06 -0700
Re: Constants and undefined behavior cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:28 +0000
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:35 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 06:29 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 16:10 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 13:05 +0000
Parentheses (was: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 14:38 +0100
Re: Parentheses (was: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
[OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 15:54 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Bart <bc@freeuk.com> - 2026-06-02 15:19 +0100
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:19 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 17:39 +0200
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 16:36 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-02 17:08 +0000
Re: [OT] Fancy graphics (was Re: this girl calls c ugly) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 19:19 +0000
Re: this girl calls c ugly scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:10 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 15:31 +0000
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-31 10:15 -0400
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 16:29 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 03:45 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 04:02 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 09:04 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 18:11 +0100
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:34 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 19:10 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:12 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:36 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:26 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 09:52 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 02:42 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:50 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 11:47 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 12:55 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 14:39 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 15:11 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 08:41 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 02:07 -0700
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:38 +0200
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:01 -0700
It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:39 +0000
Re: It is not futile to change the subject line (Was: this girl calls c ugly) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:42 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 11:46 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 11:09 +0100
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-02 05:25 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-02 14:20 +0100
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-02 04:16 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-01 15:23 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-01 16:06 -0700
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 23:24 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-06-02 11:35 +0200
Operator precedence in other (non-C, but "C-like") languages (Was: something about a girl) gazelle@shell.xmission.com (Kenny McCormack) - 2026-06-02 12:36 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 11:04 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-01 14:04 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-01 18:48 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 21:04 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:17 +0200
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 09:09 +0200
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-02 12:07 +0000
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-06-02 14:37 +0200
Microcontroller software stacks (was Re: this girl calls c ugly) scott@slp53.sl.home (Scott Lurndal) - 2026-06-02 15:06 +0000
Re: this girl calls c ugly cross@spitfire.i.gajendra.net (Dan Cross) - 2026-05-31 19:11 +0000
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 16:08 -0700
Re: this girl calls c ugly Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-05-31 16:32 -0700
Re: this girl calls c ugly Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-05-31 17:12 -0700
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-30 14:07 +0200
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 18:10 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 19:18 +0100
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:17 +0200
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-29 21:47 +0100
Re: this girl calls c ugly James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-05-29 15:57 -0400
Re: this girl calls c ugly Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-05-29 22:34 +0200
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:18 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 01:26 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-30 04:25 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-30 12:01 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-31 00:29 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-05-31 10:59 +0100
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-01 00:33 +0000
Re: this girl calls c ugly Bart <bc@freeuk.com> - 2026-06-01 02:26 +0100
Re: this girl calls c ugly David Brown <david.brown@hesbynett.no> - 2026-05-31 13:24 +0200
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 08:09 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-29 04:15 -0500
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-29 14:58 +0200
Re: this girl calls c ugly BGB <cr88192@gmail.com> - 2026-05-30 01:04 -0500
Re: this girl calls c ugly Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-05-29 23:20 +0000
Re: this girl calls c ugly Bonita Montero <Bonita.Montero@gmail.com> - 2026-05-30 11:18 +0200
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-31 09:04 -0700 |
| Message-ID | <86tsrnefac.fsf@linuxsc.com> |
| In reply to | #399545 |
Richard Harnden <richard.nospam@gmail.invalid> writes: > just write complex expressions in a way that a human can most > easily understand, Unfortunately, (1) different people have different ideas of what writing is most easily understood, and (2) different readers have different notions of which writings are easily understood, and which writings are not so easily understood. To make things worse "easily understood" is not a boolean condition, nor is it necessarily well-ordered -- "most easily understood" isn't always a well-defined quality, even for a given audience. Sadly the idea of writing in a way that is "most easily understood" has resulted in a race to the bottom, where writers are more and more encouraged to take the view that (some) readers are pretty much arbitrarily stupid, with the result that expressions become littered with scads of unnecessary parentheses that actually detract from ease of reading. Good writing is always a balance between too much and too little.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-05-31 18:11 +0100 |
| Message-ID | <10vhq39$1lpo1$1@dont-email.me> |
| In reply to | #399559 |
On 31/05/2026 17:04, Tim Rentsch wrote: > Richard Harnden <richard.nospam@gmail.invalid> writes: > >> just write complex expressions in a way that a human can most >> easily understand, > > Unfortunately, (1) different people have different ideas of what > writing is most easily understood, and (2) different readers have > different notions of which writings are easily understood, and > which writings are not so easily understood. To make things > worse "easily understood" is not a boolean condition, nor is it > necessarily well-ordered -- "most easily understood" isn't always > a well-defined quality, even for a given audience. > > Sadly the idea of writing in a way that is "most easily understood" > has resulted in a race to the bottom, where writers are more and > more encouraged to take the view that (some) readers are pretty > much arbitrarily stupid, with the result that expressions become > littered with scads of unnecessary parentheses that actually > detract from ease of reading. Good writing is always a balance > between too much and too little. Actual examples of too many parentheses? I don't think they are needed for the three main groups (unless you need to override the normal behaviour): * Arithmetic ops that everyone knows * Comparison ops which can be considered a single level (in C there are two, but they are rarely chained) * Logical AND/OR ops Most involved in coding should know the order of these groups and will know that AND takes precedence over OR because that is common. The leaves the following which are not used in the real world and which are diverse across languages: << >> & | ^ There it makes sense to use parentheses to make things clear when any of these appear, but only if there is more than one and they are mixed. I don't think that is particularly onerous to have to write, or too much clutter to read. I wouldn't call anyone stupid for using () in such cases; more pragmatic. There are some odd ones such as "." (not even considered a binary operator in some languages), and assignment, but these also commonly behave the same way across languages. And then there is ?: : a > b ? c : d # (a>b)?c:d a + b ? c : d # (a+b)?c:d The grouping of the first is probably what is intended. But in the second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't know for sure that the author didn't make a mistake or we don't know outselves. Another candidate for parentheses when there are leading or trailing binary ops involved.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-05-31 19:34 +0000 |
| Message-ID | <10vi2f8$ovl$2@reader1.panix.com> |
| In reply to | #399561 |
In article <10vhq39$1lpo1$1@dont-email.me>, Bart <bc@freeuk.com> wrote: >On 31/05/2026 17:04, Tim Rentsch wrote: >> Richard Harnden <richard.nospam@gmail.invalid> writes: >> >>> just write complex expressions in a way that a human can most >>> easily understand, >> >> Unfortunately, (1) different people have different ideas of what >> writing is most easily understood, and (2) different readers have >> different notions of which writings are easily understood, and >> which writings are not so easily understood. To make things >> worse "easily understood" is not a boolean condition, nor is it >> necessarily well-ordered -- "most easily understood" isn't always >> a well-defined quality, even for a given audience. >> >> Sadly the idea of writing in a way that is "most easily understood" >> has resulted in a race to the bottom, where writers are more and >> more encouraged to take the view that (some) readers are pretty >> much arbitrarily stupid, with the result that expressions become >> littered with scads of unnecessary parentheses that actually >> detract from ease of reading. Good writing is always a balance >> between too much and too little. > >Actual examples of too many parentheses? I was working on some code in a Unix-like kernel the other day where the original author wrote, `if ((a == 0) && (b == 1))` type expressions. The inner parentheses were totally superfluous. I removed them. As Tim wrote, there's obviously a balance to be struck between excessive verbosity and extreme concision. Over time, programmers working in a language (or a code base) do tend to internalize that some operations are more frequently misunderstood than others, and parenthesize accordingly. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-05-31 19:10 -0700 |
| Message-ID | <86zf1fc8oq.fsf@linuxsc.com> |
| In reply to | #399561 |
Bart <bc@freeuk.com> writes: > On 31/05/2026 17:04, Tim Rentsch wrote: > >> Richard Harnden <richard.nospam@gmail.invalid> writes: >> >>> just write complex expressions in a way that a human can most >>> easily understand, >> >> Unfortunately, (1) different people have different ideas of what >> writing is most easily understood, and (2) different readers have >> different notions of which writings are easily understood, and >> which writings are not so easily understood. To make things >> worse "easily understood" is not a boolean condition, nor is it >> necessarily well-ordered -- "most easily understood" isn't always >> a well-defined quality, even for a given audience. >> >> Sadly the idea of writing in a way that is "most easily understood" >> has resulted in a race to the bottom, where writers are more and >> more encouraged to take the view that (some) readers are pretty >> much arbitrarily stupid, with the result that expressions become >> littered with scads of unnecessary parentheses that actually >> detract from ease of reading. Good writing is always a balance >> between too much and too little. > > Actual examples of too many parentheses? The point of my comment is that either too many or too few is a subjective judgment, not an objective one. > And then there is ?: : > > a > b ? c : d # (a>b)?c:d > a + b ? c : d # (a+b)?c:d > > The grouping of the first is probably what is intended. But in the > second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't > know for sure that the author didn't make a mistake or we don't know > outselves. This example is so addlebrained that it's hard to imagine anyone being confused about it. Or that it's worth any expenditure of thought wondering what to do about people who are.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-01 11:12 +0100 |
| Message-ID | <10vjltg$255kd$1@dont-email.me> |
| In reply to | #399579 |
On 01/06/2026 03:10, Tim Rentsch wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 31/05/2026 17:04, Tim Rentsch wrote:
>>
>>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>>
>>>> just write complex expressions in a way that a human can most
>>>> easily understand,
>>>
>>> Unfortunately, (1) different people have different ideas of what
>>> writing is most easily understood, and (2) different readers have
>>> different notions of which writings are easily understood, and
>>> which writings are not so easily understood. To make things
>>> worse "easily understood" is not a boolean condition, nor is it
>>> necessarily well-ordered -- "most easily understood" isn't always
>>> a well-defined quality, even for a given audience.
>>>
>>> Sadly the idea of writing in a way that is "most easily understood"
>>> has resulted in a race to the bottom, where writers are more and
>>> more encouraged to take the view that (some) readers are pretty
>>> much arbitrarily stupid, with the result that expressions become
>>> littered with scads of unnecessary parentheses that actually
>>> detract from ease of reading. Good writing is always a balance
>>> between too much and too little.
>>
>> Actual examples of too many parentheses?
>
> The point of my comment is that either too many or too few is a
> subjective judgment, not an objective one.
My point was that it could be objective, at least for too many. So (a*a)
+ (b*b) would be commonly agreed to have too many, and I was extending
that to other examples in computing.
>> And then there is ?: :
>>
>> a > b ? c : d # (a>b)?c:d
>> a + b ? c : d # (a+b)?c:d
>>
>> The grouping of the first is probably what is intended. But in the
>> second, the intent might have been (a+b)?c:d, or a+(b?c:c); we don't
>> know for sure that the author didn't make a mistake or we don't know
>> outselves.
>
> This example is so addlebrained that it's hard to imagine anyone
> being confused about it. Or that it's worth any expenditure of
> thought wondering what to do about people who are.
I don't understand what the problem is with my examples. There can be
ambiguity in the mind of the person looking at such code as to how the
first terms are grouped.
These are more or less real examples, I just simplified the terms. Here
are some from MZLIB:
return (status == MZ_OK) ? MZ_BUF_ERROR : status;
return (pL == pE) ? (l_len < r_len) : (l < r);
sym = (match_dist < 512) ? s0 : s1;
return ((pState->m_last_status == TINFL_STATUS_DONE) &&
(!pState->m_dict_avail)) ? MZ_STREAM_END : MZ_OK;
I believe that in the first three, all parentheses are superflous, but
they are used anyway. Why is that?
(My preferences for ?: are that the whole thing is syntax, outside of
the precedence scheme, and that it has mandatory parentheses. That
second line would then look like this:
return (pL == pE ? l_len < r_len : l < r);
There are fewer parentheses in all, and less potential confusion. You
can even have assignments in each branch; they will not interfere with ?:.)
As for the last one, I haven't figured it out yet. But simplifying the
terms:
return ((a == b) && (!c)) ? d : e;
then the same applies: this could be:
return a == b && !c ? d : e;
However, I had to confirm this by comparing the ASTs for both.
I'd say that MZLIB is doing the right thing by not being too clever.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 12:36 +0200 |
| Message-ID | <10vjnbn$259m4$1@dont-email.me> |
| In reply to | #399585 |
On 01/06/2026 12:12, Bart wrote: > On 01/06/2026 03:10, Tim Rentsch wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 31/05/2026 17:04, Tim Rentsch wrote: >>> >>>> Richard Harnden <richard.nospam@gmail.invalid> writes: >>>> >>>>> just write complex expressions in a way that a human can most >>>>> easily understand, >>>> >>>> Unfortunately, (1) different people have different ideas of what >>>> writing is most easily understood, and (2) different readers have >>>> different notions of which writings are easily understood, and >>>> which writings are not so easily understood. To make things >>>> worse "easily understood" is not a boolean condition, nor is it >>>> necessarily well-ordered -- "most easily understood" isn't always >>>> a well-defined quality, even for a given audience. >>>> >>>> Sadly the idea of writing in a way that is "most easily understood" >>>> has resulted in a race to the bottom, where writers are more and >>>> more encouraged to take the view that (some) readers are pretty >>>> much arbitrarily stupid, with the result that expressions become >>>> littered with scads of unnecessary parentheses that actually >>>> detract from ease of reading. Good writing is always a balance >>>> between too much and too little. >>> >>> Actual examples of too many parentheses? >> >> The point of my comment is that either too many or too few is a >> subjective judgment, not an objective one. > > My point was that it could be objective, at least for too many. So (a*a) > + (b*b) would be commonly agreed to have too many, and I was extending > that to other examples in computing. > No, it is all still subjective. But the more levels of parentheses, the more consensus you are likely to get on the subjective opinions. To be "objective", you would have to have some kind of measure, with statistically significant results. If someone were to conduct a survey and measure the accuracy and thinking time for people to understand expressions written in different ways with different levels of parentheses, then there would be a basis for calling things "objective".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 14:26 -0700 |
| Message-ID | <10vktel$2glfs$1@kst.eternal-september.org> |
| In reply to | #399585 |
Bart <bc@freeuk.com> writes:
[...]
> These are more or less real examples, I just simplified the
> terms. Here are some from MZLIB:
>
> return (status == MZ_OK) ? MZ_BUF_ERROR : status;
>
> return (pL == pE) ? (l_len < r_len) : (l < r);
>
> sym = (match_dist < 512) ? s0 : s1;
>
> return ((pState->m_last_status == TINFL_STATUS_DONE) &&
> (!pState->m_dict_avail)) ? MZ_STREAM_END : MZ_OK;
>
> I believe that in the first three, all parentheses are superflous, but
> they are used anyway. Why is that?
Obviously it's because the author of the code thought it was
clearer with the parentheses (or was working under a coding standard
written by someone who thought so). I don't think there are any
deeper conclusions to be drawn. I would have written most of them
differently, but it's not a big deal.
> (My preferences for ?: are that the whole thing is syntax, outside of
> the precedence scheme, and that it has mandatory parentheses. That
> second line would then look like this:
>
> return (pL == pE ? l_len < r_len : l < r);
>
> There are fewer parentheses in all, and less potential confusion. You
> can even have assignments in each branch; they will not interfere with
> ?:.)
But the precedence scheme *is* syntax. If you prefer to think of ?:
as something other than an operator, something that that doesn't
follow the same set of rules as other operators, and if that works
for you, then that's fine. But then how do you know that
return (pL == pE ? l_len < r_len : l < r);
means
return ((pL == pE) ? (l_len < r_len) : l < r);
and not
return (pL == (pE ? l_len < r_len : l < r));
?
I know that because I know that ?: is an operator that binds more
loosely than "==".
In any case, however you think about ?:, it's clear that
"pL == pE ? l_len < r_len : l < r" is an expression, and "return"
*is* outside of the precedence scheme. The outer parentheses are
superfluous but harmless. (Personally, I dislike parenthesizing
the expression in a return statement.)
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 09:52 +0200 |
| Message-ID | <10vjdn8$22tgu$1@dont-email.me> |
| In reply to | #399561 |
On 31/05/2026 19:11, Bart wrote: > On 31/05/2026 17:04, Tim Rentsch wrote: >> Richard Harnden <richard.nospam@gmail.invalid> writes: >> >>> just write complex expressions in a way that a human can most >>> easily understand, >> >> Unfortunately, (1) different people have different ideas of what >> writing is most easily understood, and (2) different readers have >> different notions of which writings are easily understood, and >> which writings are not so easily understood. To make things >> worse "easily understood" is not a boolean condition, nor is it >> necessarily well-ordered -- "most easily understood" isn't always >> a well-defined quality, even for a given audience. >> >> Sadly the idea of writing in a way that is "most easily understood" >> has resulted in a race to the bottom, where writers are more and >> more encouraged to take the view that (some) readers are pretty >> much arbitrarily stupid, with the result that expressions become >> littered with scads of unnecessary parentheses that actually >> detract from ease of reading. Good writing is always a balance >> between too much and too little. > > Actual examples of too many parentheses? Any source code written in LISP :-) (And for too few parentheses, any source code in Forth.) From a quick grep of an SDK in a project I am working on, I saw this example : if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U)) The number of parentheses there is so high it's hard to see that not only is there an unnecessary extra parentheses for the first || operator, but there is a second set of extra parentheses around it. Eliminating these would give : if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U)) or, with an extra space for clarity, if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) ) That still leaves extra parentheses around the equality operators, but the decision to keep or remove them is subjective (as is the choice of "pData1 == NULL" vs. "!pData1"). But IMHO, the original line had at least two sets of completely redundant and unhelpful parentheses which made it harder to read - the reader is left wondering whether these parentheses are there for a purpose and have an effect on what should have been a simple and clear expression. The SDK also contains examples of parentheses used because it mixes relatively rare operators (shifts and binary operators). Parentheses around such sub-expressions are not uncommon, and can definitely be helpful, but the quantity here makes things hard to read. Ironically, though it is a macro, there are not "safety" parentheses around the argument in the expression. And yes, these really are the names of the macro in this code. #define CONVERTARGB88882ARGB4444(Color) \ ((((Color & 0xFFU) >> 4) & 0xFU) |\ (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\ (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \ (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12)) #define CONVERTRGB5652ARGB8888(Color) \ (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\ ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\ ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000) It can be argued that the parentheses themselves are not the problem here - it is doing too much in one expression. Static inline functions would make things clearer, as would a separation of the steps of breaking down the original colour format into parts, scaling or conversions, then building up the new colour format. Different named types for the different formats would go a long way towards usability and safety - at least using typedefs, but preferably using structs to make real different types. And surely nicer names could have been found!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 02:42 -0700 |
| Message-ID | <10vjk5s$24d8c$2@kst.eternal-september.org> |
| In reply to | #399582 |
David Brown <david.brown@hesbynett.no> writes:
> On 31/05/2026 19:11, Bart wrote:
[...]
>> Actual examples of too many parentheses?
>
> Any source code written in LISP :-)
>
> (And for too few parentheses, any source code in Forth.)
>
>
> From a quick grep of an SDK in a project I am working on, I saw this
> example :
>
> if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U))
>
> The number of parentheses there is so high it's hard to see that not
> only is there an unnecessary extra parentheses for the first ||
> operator, but there is a second set of extra parentheses around
> it. Eliminating these would give :
>
> if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U))
>
> or, with an extra space for clarity,
>
> if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) )
>
> That still leaves extra parentheses around the equality operators, but
> the decision to keep or remove them is subjective (as is the choice of
> "pData1 == NULL" vs. "!pData1").
Yeah, I'd write that as
if (pData1 == NULL || pData2 == NULL || Length == 0U)
The fact that || binds more loosely than == is one of those things
that I arbitrarily find sufficiently intuitive.
[...]
> And yes, these really are the names of the macro in this code.
>
>
> #define CONVERTARGB88882ARGB4444(Color) \
> ((((Color & 0xFFU) >> 4) & 0xFU) |\
> (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\
> (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \
> (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12))
>
> #define CONVERTRGB5652ARGB8888(Color) \
> (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\
> ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\
> ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000)
In a macro definition, I'd parenthesize each occurrence of Color,
in case the argument is a more complicated expression, as well as
parenthesizing the entire definition (the latter was done here).
The rest of the parentheses feel excessive, but I frankly can't be
bothered to figure out which can be omitted without hurting clarity.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 12:50 +0200 |
| Message-ID | <10vjo5q$259m3$1@dont-email.me> |
| In reply to | #399584 |
On 01/06/2026 11:42, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 31/05/2026 19:11, Bart wrote: > [...] >>> Actual examples of too many parentheses? >> >> Any source code written in LISP :-) >> >> (And for too few parentheses, any source code in Forth.) >> >> >> From a quick grep of an SDK in a project I am working on, I saw this >> example : >> >> if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U)) >> >> The number of parentheses there is so high it's hard to see that not >> only is there an unnecessary extra parentheses for the first || >> operator, but there is a second set of extra parentheses around >> it. Eliminating these would give : >> >> if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U)) >> >> or, with an extra space for clarity, >> >> if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) ) >> >> That still leaves extra parentheses around the equality operators, but >> the decision to keep or remove them is subjective (as is the choice of >> "pData1 == NULL" vs. "!pData1"). > > Yeah, I'd write that as > > if (pData1 == NULL || pData2 == NULL || Length == 0U) > > The fact that || binds more loosely than == is one of those things > that I arbitrarily find sufficiently intuitive. > Yes, the precedence levels of "==" and "||" (and "&&") are clearly intentional, and I think a lot of C programmers are happy with skipping the parentheses here. But some people would prefer to have the sub-expressions parenthesised, and I think that is fair enough too - it's not going to cause anyone extra difficulties in reading the line. > [...] > >> And yes, these really are the names of the macro in this code. >> >> >> #define CONVERTARGB88882ARGB4444(Color) \ >> ((((Color & 0xFFU) >> 4) & 0xFU) |\ >> (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\ >> (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \ >> (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12)) >> >> #define CONVERTRGB5652ARGB8888(Color) \ >> (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\ >> ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\ >> ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000) > > In a macro definition, I'd parenthesize each occurrence of Color, > in case the argument is a more complicated expression, as well as > parenthesizing the entire definition (the latter was done here). > The rest of the parentheses feel excessive, but I frankly can't be > bothered to figure out which can be omitted without hurting clarity. > That's the problem with code like that. People will think "that's a mess - I'll just assume / hope that it is correct". It is very difficult to check in code reviews, or to maintain, modify or adapt, so no one will bother figuring it out. It is "write-only" code. But while I know there are certainly some of the parentheses that could be removed, I am not sure that would actually improve the readability significantly. Like many people, I prefer not to rely on knowledge of the relative precedences of shifts and bitwise operators. My preference would be for major refactoring, not for removing (or adding) parentheses.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-06-01 11:47 +0100 |
| Message-ID | <10vjnv7$25mnf$1@dont-email.me> |
| In reply to | #399582 |
On 01/06/2026 08:52, David Brown wrote:
> On 31/05/2026 19:11, Bart wrote:
>> On 31/05/2026 17:04, Tim Rentsch wrote:
>>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>>
>>>> just write complex expressions in a way that a human can most
>>>> easily understand,
>>>
>>> Unfortunately, (1) different people have different ideas of what
>>> writing is most easily understood, and (2) different readers have
>>> different notions of which writings are easily understood, and
>>> which writings are not so easily understood. To make things
>>> worse "easily understood" is not a boolean condition, nor is it
>>> necessarily well-ordered -- "most easily understood" isn't always
>>> a well-defined quality, even for a given audience.
>>>
>>> Sadly the idea of writing in a way that is "most easily understood"
>>> has resulted in a race to the bottom, where writers are more and
>>> more encouraged to take the view that (some) readers are pretty
>>> much arbitrarily stupid, with the result that expressions become
>>> littered with scads of unnecessary parentheses that actually
>>> detract from ease of reading. Good writing is always a balance
>>> between too much and too little.
>>
>> Actual examples of too many parentheses?
>
> Any source code written in LISP :-)
>
> (And for too few parentheses, any source code in Forth.)
>
>
> From a quick grep of an SDK in a project I am working on, I saw this
> example :
>
> if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U))
>
> The number of parentheses there is so high it's hard to see that not
> only is there an unnecessary extra parentheses for the first ||
> operator, but there is a second set of extra parentheses around it.
> Eliminating these would give :
>
> if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U))
>
> or, with an extra space for clarity,
>
> if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) )
>
> That still leaves extra parentheses around the equality operators, but
> the decision to keep or remove them is subjective (as is the choice of
> "pData1 == NULL" vs. "!pData1").
Maybe it's due to || being a symbol; compare:
if (pData1 == NULL || pData2 == NULL || Length == 0U)
if (pData1 == NULL or pData2 == NULL or Length == 0U)
To me, || seems to draw in the terms on either side as strongly as ==.
That happens less using 'or'.
(Both are valid C if using iso646.h.)
> But IMHO, the original line had at least two sets of completely
> redundant and unhelpful parentheses which made it harder to read - the
> reader is left wondering whether these parentheses are there for a
> purpose and have an effect on what should have been a simple and clear
> expression.
The pattern seems to be '((a || b)) || c) || d' so maybe the author
didn't understand that || is parsed LTR anyway.
>
> The SDK also contains examples of parentheses used because it mixes
> relatively rare operators (shifts and binary operators). Parentheses
> around such sub-expressions are not uncommon, and can definitely be
> helpful, but the quantity here makes things hard to read. Ironically,
> though it is a macro, there are not "safety" parentheses around the
> argument in the expression.
>
> And yes, these really are the names of the macro in this code.
>
>
> #define CONVERTARGB88882ARGB4444(Color) \
> ((((Color & 0xFFU) >> 4) & 0xFU) |\
> (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\
> (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \
> (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12))
> #define CONVERTRGB5652ARGB8888(Color) \
> (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\
> ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\
> ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000)
>
> It can be argued that the parentheses themselves are not the problem
> here - it is doing too much in one expression. Static inline functions
> would make things clearer, as would a separation of the steps of
> breaking down the original colour format into parts, scaling or
> conversions, then building up the new colour format. Different named
> types for the different formats would go a long way towards usability
> and safety - at least using typedefs, but preferably using structs to
> make real different types. And surely nicer names could have been found!
>
Your examples actually look reasonable. In fact, it could probably do
with more parentheses around 'Color'... (I've just seen you've already
mentioned this!)
The first part of the second has to apply 6 operations to 'Color' in
strict LTR order. Using parentheses ensures not having to worry about
precedence, since the ops are '>> & * + >> <<'
The macro names seem self-explanatory too, although they could do with
some underscores.
But anything involving macros probably doesn't count; you expect () to
be heavily used in the expansion.
This is an example from Lua:
op_arith(L, l_addi, luai_numadd);
On the face of it, perfectly reasonable. But it expands to this:
{TValue*v1=(&((base+(((void)0),((((int)((((i)>>((((0+7)+8)+1)))&
((~((~(Instruction)0)<<(8)))<<(0))))))))))->val);TValue*v2=(&((
base+(((void)0),((((int)((((i)>>(((((0+7)+8)+1)+8)))&((~((~(
Instruction)0)<<(8)))<<(0))))))))))->val);{StkId ra=(base+(((int)
((((i)>>((0+7)))&((~((~(Instruction)0)<<(8)))<<(0)))))));if(((((v1)
)->tt_)==(((3)|((0)<<4))))&&((((v2))->tt_)==(((3)|((0)<<4))))){
lua_Integer i1=(((void)0),(((v1)->value_).i));lua_Integer i2=(((void)
0),(((v2)->value_).i));pc++;{TValue*io=((&(ra)->val));((io)->value_)
.i=(((lua_Integer)(((lua_Unsigned)(i1))+((lua_Unsigned)(i2)))));((io)
->tt_=(((3)|((0)<<4))));};}else{lua_Number n1;lua_Number n2;if((((((v1))
->tt_)==(((3)|((1)<<4))))?((n1)=(((void)0),(((v1)->value_).n)),1):(((((
v1))->tt_)==(((3)|((0)<<4))))?((n1)=((lua_Number)(((((void)0),(((v1)->
value_).i))))),1):0))&&(((((v2))->tt_)==(((3)|((1)<<4))))?((n2)=(((void)
0),(((v2)->value_).n)),1):(((((v2))->tt_)==(((3)|((0)<<4))))?((n2)=((
lua_Number)(((((void)0),(((v2)->value_).i))))),1):0))){pc++;{TValue*
io=((&(ra)->val));((io)->value_).n=(((n1)+(n2)));((io)->tt_=(((3)|
((1)<<4))));};}};};};
(I had fun debugging this at one time in my compiler. I've no idea how
the original developer did so.)
Not too many () in the macro definitions, but I can only see the top
level; here deeply nested macros are used.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-01 12:55 +0200 |
| Message-ID | <10vjofv$259m3$2@dont-email.me> |
| In reply to | #399587 |
On 01/06/2026 12:47, Bart wrote:
> On 01/06/2026 08:52, David Brown wrote:
>> On 31/05/2026 19:11, Bart wrote:
>>> On 31/05/2026 17:04, Tim Rentsch wrote:
>>>> Richard Harnden <richard.nospam@gmail.invalid> writes:
>>>>
>>>>> just write complex expressions in a way that a human can most
>>>>> easily understand,
>>>>
>>>> Unfortunately, (1) different people have different ideas of what
>>>> writing is most easily understood, and (2) different readers have
>>>> different notions of which writings are easily understood, and
>>>> which writings are not so easily understood. To make things
>>>> worse "easily understood" is not a boolean condition, nor is it
>>>> necessarily well-ordered -- "most easily understood" isn't always
>>>> a well-defined quality, even for a given audience.
>>>>
>>>> Sadly the idea of writing in a way that is "most easily understood"
>>>> has resulted in a race to the bottom, where writers are more and
>>>> more encouraged to take the view that (some) readers are pretty
>>>> much arbitrarily stupid, with the result that expressions become
>>>> littered with scads of unnecessary parentheses that actually
>>>> detract from ease of reading. Good writing is always a balance
>>>> between too much and too little.
>>>
>>> Actual examples of too many parentheses?
>>
>> Any source code written in LISP :-)
>>
>> (And for too few parentheses, any source code in Forth.)
>>
>>
>> From a quick grep of an SDK in a project I am working on, I saw this
>> example :
>>
>> if ((((pData1 == NULL) || (pData2 == NULL))) || (Length == 0U))
>>
>> The number of parentheses there is so high it's hard to see that not
>> only is there an unnecessary extra parentheses for the first ||
>> operator, but there is a second set of extra parentheses around it.
>> Eliminating these would give :
>>
>> if ((pData1 == NULL) || (pData2 == NULL) || (Length == 0U))
>>
>> or, with an extra space for clarity,
>>
>> if ( (pData1 == NULL) || (pData2 == NULL) || (Length == 0U) )
>>
>> That still leaves extra parentheses around the equality operators, but
>> the decision to keep or remove them is subjective (as is the choice of
>> "pData1 == NULL" vs. "!pData1").
>
> Maybe it's due to || being a symbol; compare:
>
> if (pData1 == NULL || pData2 == NULL || Length == 0U)
>
> if (pData1 == NULL or pData2 == NULL or Length == 0U)
>
> To me, || seems to draw in the terms on either side as strongly as ==.
> That happens less using 'or'.
>
> (Both are valid C if using iso646.h.)
>
>
>> But IMHO, the original line had at least two sets of completely
>> redundant and unhelpful parentheses which made it harder to read - the
>> reader is left wondering whether these parentheses are there for a
>> purpose and have an effect on what should have been a simple and clear
>> expression.
>
> The pattern seems to be '((a || b)) || c) || d' so maybe the author
> didn't understand that || is parsed LTR anyway.
>
>>
>> The SDK also contains examples of parentheses used because it mixes
>> relatively rare operators (shifts and binary operators). Parentheses
>> around such sub-expressions are not uncommon, and can definitely be
>> helpful, but the quantity here makes things hard to read. Ironically,
>> though it is a macro, there are not "safety" parentheses around the
>> argument in the expression.
>>
>> And yes, these really are the names of the macro in this code.
>>
>>
>> #define CONVERTARGB88882ARGB4444(Color) \
>> ((((Color & 0xFFU) >> 4) & 0xFU) |\
>> (((((Color & 0xFF00U) >> 8) >> 4) & 0xFU) << 4) |\
>> (((((Color & 0xFF0000U) >> 16) >> 4) & 0xFU) << 8) | \
>> (((((Color & 0xFF000000U) >> 24) >> 4) & 0xFU) << 12))
>> #define CONVERTRGB5652ARGB8888(Color) \
>> (((((((Color >> 11) & 0x1FU) * 527) + 23) >> 6) << 16) |\
>> ((((((Color >> 5) & 0x3FU) * 259) + 33) >> 6) << 8) |\
>> ((((Color & 0x1FU) * 527) + 23) >> 6) | 0xFF000000)
>>
>> It can be argued that the parentheses themselves are not the problem
>> here - it is doing too much in one expression. Static inline
>> functions would make things clearer, as would a separation of the
>> steps of breaking down the original colour format into parts, scaling
>> or conversions, then building up the new colour format. Different
>> named types for the different formats would go a long way towards
>> usability and safety - at least using typedefs, but preferably using
>> structs to make real different types. And surely nicer names could
>> have been found!
>>
> Your examples actually look reasonable. In fact, it could probably do
> with more parentheses around 'Color'... (I've just seen you've already
> mentioned this!)
>
> The first part of the second has to apply 6 operations to 'Color' in
> strict LTR order. Using parentheses ensures not having to worry about
> precedence, since the ops are '>> & * + >> <<'
>
> The macro names seem self-explanatory too, although they could do with
> some underscores.
Indeed.
>
> But anything involving macros probably doesn't count; you expect () to
> be heavily used in the expansion.
I think macro definitions "count", as do how the macros are used in
code. But the full expansions do not "count" as they are not something
normally read or written by the programmer. (I appreciate that you need
to see such things sometimes when implementing a compiler, and
occasionally people look at the output of a pre-processor, but in normal
use, the appearance of a macro expansion does not matter.)
>
> This is an example from Lua:
>
> op_arith(L, l_addi, luai_numadd);
>
> On the face of it, perfectly reasonable. But it expands to this:
>
> {TValue*v1=(&((base+(((void)0),((((int)((((i)>>((((0+7)+8)+1)))&
> ((~((~(Instruction)0)<<(8)))<<(0))))))))))->val);TValue*v2=(&((
> base+(((void)0),((((int)((((i)>>(((((0+7)+8)+1)+8)))&((~((~(
> Instruction)0)<<(8)))<<(0))))))))))->val);{StkId ra=(base+(((int)
> ((((i)>>((0+7)))&((~((~(Instruction)0)<<(8)))<<(0)))))));if(((((v1)
> )->tt_)==(((3)|((0)<<4))))&&((((v2))->tt_)==(((3)|((0)<<4))))){
> lua_Integer i1=(((void)0),(((v1)->value_).i));lua_Integer i2=(((void)
> 0),(((v2)->value_).i));pc++;{TValue*io=((&(ra)->val));((io)->value_)
> .i=(((lua_Integer)(((lua_Unsigned)(i1))+((lua_Unsigned)(i2)))));((io)
> ->tt_=(((3)|((0)<<4))));};}else{lua_Number n1;lua_Number n2;if((((((v1))
> ->tt_)==(((3)|((1)<<4))))?((n1)=(((void)0),(((v1)->value_).n)),1):(((((
> v1))->tt_)==(((3)|((0)<<4))))?((n1)=((lua_Number)(((((void)0),(((v1)->
> value_).i))))),1):0))&&(((((v2))->tt_)==(((3)|((1)<<4))))?((n2)=(((void)
> 0),(((v2)->value_).n)),1):(((((v2))->tt_)==(((3)|((0)<<4))))?((n2)=((
> lua_Number)(((((void)0),(((v2)->value_).i))))),1):0))){pc++;{TValue*
> io=((&(ra)->val));((io)->value_).n=(((n1)+(n2)));((io)->tt_=(((3)|
> ((1)<<4))));};}};};};
>
> (I had fun debugging this at one time in my compiler. I've no idea how
> the original developer did so.)
I assume the author did so built it up in parts. The readability is in
the source - and the source is "op_arith(L, l_addi, luai_numadd);" -
there are not too many parentheses there.
>
> Not too many () in the macro definitions, but I can only see the top
> level; here deeply nested macros are used.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 14:39 -0700 |
| Message-ID | <10vku5o$2glfs$2@kst.eternal-september.org> |
| In reply to | #399587 |
Bart <bc@freeuk.com> writes:
> On 01/06/2026 08:52, David Brown wrote:
[...]
>> That still leaves extra parentheses around the equality operators,
>> but the decision to keep or remove them is subjective (as is the
>> choice of "pData1 == NULL" vs. "!pData1").
>
> Maybe it's due to || being a symbol; compare:
>
> if (pData1 == NULL || pData2 == NULL || Length == 0U)
>
> if (pData1 == NULL or pData2 == NULL or Length == 0U)
>
> To me, || seems to draw in the terms on either side as strongly as
> ==. That happens less using 'or'.
>
> (Both are valid C if using iso646.h.)
The "and" macro in <iso646.h> is exactly equivalent to "||".
If your intuition tells you they have different precedences, that
could be a problem. On the other hand, if you choose to use them
differently in ways that don't break anything, that's fine.
Digression: Perl borrows most or all of C's operators, and keeps
the same precedences. "Operators borrowed from C keep the same
precedence relationship with each other, even where C's precedence
is slightly screwy." But Perl has "and" and "or" operators that
work like "&&" and "||" but have lower precedence (that turns out
to be convenient in some contexts).
I vaguely recall that there's some language that uses the ?: syntax
for the conditional operator, but with a different precedence and/or
associativity than C. I can't remember which language it is.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-01 15:11 -0700 |
| Message-ID | <10vl02a$2glfs$4@kst.eternal-september.org> |
| In reply to | #399595 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> I vaguely recall that there's some language that uses the ?: syntax
> for the conditional operator, but with a different precedence and/or
> associativity than C. I can't remember which language it is.
The language I was thinking of is PHP. C's ?: operator associates
right-to-left, which makes it possible to write chained conditional
expressions like:
cond1 ? expr1 :
cond2 ? expr2 :
cond3 ? expr3 :
default_expr
PHP's ?: operator originally associated right-to-left.
Newer versions of PHP require parentheses.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-06-02 08:41 +0200 |
| Message-ID | <10vltvd$2ne3j$1@dont-email.me> |
| In reply to | #399596 |
On 02/06/2026 00:11, Keith Thompson wrote: > Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > [...] >> I vaguely recall that there's some language that uses the ?: syntax >> for the conditional operator, but with a different precedence and/or >> associativity than C. I can't remember which language it is. > > The language I was thinking of is PHP. C's ?: operator associates > right-to-left, which makes it possible to write chained conditional > expressions like: > > cond1 ? expr1 : > cond2 ? expr2 : > cond3 ? expr3 : > default_expr > > PHP's ?: operator originally associated right-to-left. > Newer versions of PHP require parentheses. > I thought you were thinking of C++, where ? has the same precedence as assignment, while in C it has higher precedence. It does not make a lot of difference, and if you are writing an expression where it matters, then I think parentheses would be a good idea. <https://cppreference.com/c/language/operator_precedence> <https://cppreference.com/cpp/language/operator_precedence>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 02:07 -0700 |
| Message-ID | <10vm6h4$2qdor$1@kst.eternal-september.org> |
| In reply to | #399601 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/06/2026 00:11, Keith Thompson wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>>> I vaguely recall that there's some language that uses the ?: syntax
>>> for the conditional operator, but with a different precedence and/or
>>> associativity than C. I can't remember which language it is.
>>
>> The language I was thinking of is PHP. C's ?: operator associates
>> right-to-left, which makes it possible to write chained conditional
>> expressions like:
>> cond1 ? expr1 :
>> cond2 ? expr2 :
>> cond3 ? expr3 :
>> default_expr
>> PHP's ?: operator originally associated right-to-left.
>> Newer versions of PHP require parentheses.
>
> I thought you were thinking of C++, where ? has the same precedence as
> assignment, while in C it has higher precedence. It does not make a
> lot of difference, and if you are writing an expression where it
> matters, then I think parentheses would be a good idea.
>
> <https://cppreference.com/c/language/operator_precedence>
> <https://cppreference.com/cpp/language/operator_precedence>
Hmm. I'm not sure I either follow or trust those tables.
Looking at the grammar in the C++ standard, there is a difference.
C has:
conditional-expression:
logical-OR-expression
logical-OR-expression ? expression : conditional-expression
while C++ has:
conditional-expression:
logical-or-expression
logical-or-expression ? expression : assignment-expression
But the difference isn't mentioned in the Compatibility annex of the C++
standard.
I'd be interested in seeing a conditional expression whose legality or
semantics differs between C and C++.
(Digression: I hate the fact that such a long and sometimes
informative thread has such a stupid subject header.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-06-02 11:38 +0200 |
| Message-ID | <10vm8au$3uus8$11@dont-email.me> |
| In reply to | #399604 |
On 2026-06-02 11:07, Keith Thompson wrote: > [...] > > (Digression: I hate the fact that such a long and sometimes > informative thread has such a stupid subject header.) And what did prevent you from changing it? :-} Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-06-02 05:01 -0700 |
| Message-ID | <10vmgn2$2tjoi$1@kst.eternal-september.org> |
| In reply to | #399606 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-06-02 11:07, Keith Thompson wrote:
>> [...]
>> (Digression: I hate the fact that such a long and sometimes
>> informative thread has such a stupid subject header.)
>
> And what did prevent you from changing it? :-}
Futility. At best, I could start a new subthread. The existing
subject line would live on.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-06-02 12:39 +0000 |
| Subject | It is not futile to change the subject line (Was: this girl calls c ugly) |
| Message-ID | <10vmitc$o9ge$2@news.xmission.com> |
| In reply to | #399614 |
In article <10vmgn2$2tjoi$1@kst.eternal-september.org>, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-06-02 11:07, Keith Thompson wrote: >>> [...] >>> (Digression: I hate the fact that such a long and sometimes >>> informative thread has such a stupid subject header.) >> >> And what did prevent you from changing it? :-} > >Futility. At best, I could start a new subthread. The existing >subject line would live on. See. That wasn't so hard, was it? I maintain that there are several good reasons why changing the Subject line is a good thing. Many other people disagree with me, but I don't care about that. It is, as you imply, especially a good idea where, as here, the original (i.e., carried) Subject line is dumb. -- I shot a man on Fifth Aveneue, just to see him die.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2026-06-02 12:42 +0000 |
| Subject | Re: It is not futile to change the subject line (Was: this girl calls c ugly) |
| Message-ID | <10vmj31$o9ge$3@news.xmission.com> |
| In reply to | #399621 |
In article <10vmitc$o9ge$2@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> wrote:
...
>I maintain that there are several good reasons why changing the Subject
>line is a good thing. Many other people disagree with me, but I don't care
>about that.
>
>It is, as you imply, especially a good idea where, as here, the original
>(i.e., carried) Subject line is dumb.
Oh, and please read this, which I recently composed on the subject:
3 Reasons Why People Don't Change Subject Lines
1) Because they don't know how (and can't be bothered to learn). Or,
eqv, that whatever crappy newsreader they are using makes it difficult
or impossible to do so.
2) Because they think it is a violation of netiquette to do so. I.e.,
they think it "breaks" the thread". The theory is that doing so creates
problems for people who use poor newsreaders.
3) Because they get a perverse thrill out of keeping an old, totally
inappropriate thread title, when they clearly know better.
--
Many people in the American South think that DJT is, and will be remembered
as, one of the best presidents in US history. They are absolutely correct.
He is currently at number 46 on the list. High praise, indeed!
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web