Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Memorizing C operator precedence Date: Mon, 25 Apr 2022 15:16:48 -0700 Organization: A noiseless patient Spider Lines: 61 Message-ID: <86levs6c6n.fsf@linuxsc.com> References: <20220413163721.82@kylheku.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="e7f354bf3c65e91fece722955444236f"; logging-data="32215"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+UOlxtW1dvvbihn+ijS5mrvkVchtNpSmw=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:Pgbt91xMP90/+gX3efQvvLY6QLw= sha1:vWbtvWUTM3X2uBaX1HgOt6Y2WVo= Xref: csiph.com comp.lang.c:165935 Alan Mackenzie writes: > Kaz Kylheku <480-992-1380@kylheku.com> wrote: > >> On 2022-04-13, Alan Mackenzie 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.. :)