Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #165935
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Memorizing C operator precedence |
| Date | 2022-04-25 15:16 -0700 |
| Organization | A noiseless patient Spider |
| Message-ID | <86levs6c6n.fsf@linuxsc.com> (permalink) |
| References | <memo-20220412132213@ram.dialup.fu-berlin.de> <t34f1f$s4u$1@gioia.aioe.org> <t373kj$1avk$1@news.muc.de> <20220413163721.82@kylheku.com> <t38tjs$cnl$1@news.muc.de> |
Alan Mackenzie <acm@muc.de> writes: > Kaz Kylheku <480-992-1380@kylheku.com> wrote: > >> On 2022-04-13, Alan Mackenzie <acm@muc.de> wrote: [...] >>> Too many parentheses can make C code difficult to read. Difficult >>> to read translates to "more bugs". A knowledge of C's precedence >>> levels, at least to a moderate degree, can help avoid such bugs. I definitely agree with this. >> Too much complexity in one expression makes it hard to read. I also agree with this. >> Other >> than breaking it up into smaller expression, what can help is to >> split it into multiple lines and use indentation. Sometimes, but rarely. In most cases another choice is better. > This is a common attitude, and I'm sure it is wrong a lot of the time. > Breaking up a complicated expression _fragments_ it - it spreads it over > a greater number of source code lines, some of which may not be visible > on the screen. While each fragment may in itself be easier to read, the > entire expression has become more difficult. > >> Parenthesized expressions are much more amenable for splitting across >> lines and indenting than pure infix operator expressions. Yuck. Any expression complicated enough to need parentheses _and_ multiple lines _and_ some indication of nesting merits rewriting into simpler components. > I'm not sure I agree with this, my background being the maintainer of > Emacs's CC Mode. > > How about a real world example? In the following (from Emacs's > syntax.c): > > if (code == Sendcomment > && SYNTAX_FLAGS_COMMENT_STYLE (syntax, 0) == style > && (SYNTAX_FLAGS_COMMENT_NESTED (syntax) ? > (nesting > 0 && --nesting == 0) : nesting < 0) > && !comment_ender_quoted (from, from_byte, syntax)) > > , which is a moderately complicated example, extra parentheses around > the operands of the &&s would clutter up the code rather than clarifying > it. Yet the whole expression being on just five lines makes it > relatively easy to understand. I'm a longtime emacs user, and definitely a fan, but this code is horrible, on several different levels. I agree that adding extra parentheses around the &&s operands would make things worse, but it's already way below threshold for any reasonable standard of code review. Just my unabashed impressions.. :)
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
Re: Memorizing C operator precedence Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2022-04-12 18:05 +0000
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-13 18:09 +0000
Re: Memorizing C operator precedence Siri Cruise <chine.bleu@yahoo.com> - 2022-04-13 15:23 -0700
Re: Memorizing C operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-13 23:36 +0000
Re: Memorizing C operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-13 23:48 +0000
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-14 10:38 +0000
Re: Memorizing C operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-14 21:05 +0000
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-16 14:27 +0000
Re: Memorizing C operator precedence Paul N <gw7rib@aol.com> - 2022-04-23 10:23 -0700
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-25 10:21 +0000
Re: Memorizing C operator precedence Vir Campestris <vir.campestris@invalid.invalid> - 2022-04-25 16:43 +0100
Re: Memorizing C operator precedence Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-26 03:02 -0700
Re: Memorizing C operator precedence Kaz Kylheku <480-992-1380@kylheku.com> - 2022-04-26 13:58 +0000
Re: Memorizing C operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 14:48 -0700
Re: Memorizing C operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 15:16 -0700
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-26 10:34 +0000
Re: Memorizing C operator precedence Ben <ben.usenet@bsb.me.uk> - 2022-04-26 13:13 +0100
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-26 17:25 +0000
Re: Memorizing C operator precedence Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-26 06:12 -0700
Re: Memorizing C operator precedence Alan Mackenzie <acm@muc.de> - 2022-04-26 17:17 +0000
Re: Memorizing C operator precedence Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-30 07:05 -0700
Re: Memorizing C operator precedence David Brown <david.brown@hesbynett.no> - 2022-04-14 12:39 +0200
csiph-web