Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: [PC] Simple AST Date: Wed, 06 Mar 2019 22:12:33 -0800 Organization: None to speak of Lines: 69 Message-ID: References: <28f4e80d-4ff5-44d3-bdec-eb593f551575@googlegroups.com> <86ef7kufly.fsf@mailhub.linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="738d12f7d1c8a4ce3bc3c27b9756e98f"; logging-data="5698"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ymy7RmBdsMyQgdL6Sj0Fw" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:QFpkvBIXE3zgV72aoObzYfOw3Sg= sha1:RUBR7EpLJaf5gp7oRXmRq5doxFI= Xref: csiph.com comp.lang.c:141764 "Pascal J. Bourguignon" writes: > Keith Thompson writes: >> "Pascal J. Bourguignon" writes: >> [...] >>> We are not looking at landscape and scanning for predators here. >>> >>> We're looking at code that needs to give the human reader a conceptual >>> structure isomorphe to what the "semantics" implemented by the language >>> implementation produces. >>> >>> a = b+c * d; // spaces fail all the time. >> >> So don't do that. How often do you actually see code like that? >> >> a = b + c*d; >> >> It would be nice if compilers warned about misleading spaces in >> expressions (perhaps some do). > > Often enough. But the worst part, is that I never encoutered any C > programmer able to recite from memory the list of all C opertors sorted > by their exact priority level. Therefore not using systematically > parentheses in any C expressions is a sure way to introduce slimy bugs. > > (I'm not able to do it for C either, when I programmed in pascal, I > could do it for pascal operators). If you want to argue that it's good to use parentheses to make precedence explicit when using operators whose precedence a reader might not reasonably be expected to know, I agree. We might differ on which operators those are, but for example I'd certainly parenthesize a | (b ^ c) even though it's equivalent to a | b ^ c If I saw a | b^c I'd assume that the author *thinks* that ^ binds more tightly than | -- but I'd probably check that assumption, and consider adding parentheses if I were in a position to do so. If I saw a|b ^ c I'd make a similar assumption and find that the author either was mistaken or was being deliberately misleading. But we were talking about a = b+c * d; which is clearly misleading to anyone who knows the relative precedence of + and * (and I'm confortable assuming that any reasonably skilled C programmer does know that). If I actually saw that, I wouldn't assume that either changing the spacing or adding the parentheses would fix the problem. I'd have to consider that there might be other mistakes. But to get back to the point, I find this: a = b + c*d; or even this: a = b + c * d; more legible than what you suggested upthread: a=(b+(c*d)); I usually put spaces around binary operators, but I might omit them to emphasize known precedence. The possibility of adding spaces *and getting them wrong* is, I believe, something of a straw man argument. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */