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


Groups > comp.lang.c > #165935

Re: Memorizing C operator precedence

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar


Thread

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