From: cross@spitfire.i.gajendra.net   
      
   In article <10822mn$3pb8v$1@dont-email.me>,   
   Arne Vajhøj   wrote:   
   >On 8/18/2025 11:00 PM, Lawrence D’Oliveiro wrote:   
   >> On Mon, 18 Aug 2025 21:49:29 -0400, Arne Vajhøj wrote:   
   >>   
   >>> On 8/18/2025 7:59 PM, Lawrence D’Oliveiro wrote:   
   >>>>>   
   >>>> On Mon, 18 Aug 2025 19:48:16 -0400, Arne Vajhøj wrote:   
   >>>>>   
   >>>>> On 8/18/2025 7:45 PM, Lawrence D’Oliveiro wrote:   
   >>>>>>   
   >>>>>> Parentheses are best used lightly -- where needed, maybe a little   
   >>>>>> bit more than that, and that’s it.   
   >>>>>>   
   >>>>>> Otherwise parenthesis clutter introduces its own obstacles to   
   >>>>>> readability.   
   >>>>>   
   >>>>> That is not the mantra among people who try to prevent future   
   >>>>> errors.   
   >>>>   
   >>>> There are people who just repeat what they are told, aren’t there,   
   >>>> instead of learning from actual experience.   
   >>>   
   >>> It is the recommendation from people with actual experience.   
   >>>   
   >>> One book that recommend it is "The Practice of Programming".   
   >>> Brian Kernighan and Rob Pike.   
   >>   
   >> One wonders how much experience they really have, across how many   
   >> different languages.   
      
   (Wow.)   
      
   >Brian Kernighan and Rob Pike? A lot! :-)   
      
   It may help to read what they actually wrote in TPoP; on page 6:   
      
   |_Parenthesize to resolve ambiguity_. Parentheses specify   
   |grouping and can be used to make the intent clear even when   
   |they are not required.  The inner parentheses in the previous   
   |example are not necessary, but they don't hurt, either.   
   |Seasoned programmers might omit them, because the relational   
   |operators (< <= == != >= >) have higher precedence than the   
   |logical operators (&& and ||).   
   |   
   |When mixing unrelated operators, though, it's a good idea to   
   |parenthesize.  C and its friends present pernicious precedence   
   |problems, and it's easy to make a mistake.   
      
   For reference, the "previous example" they mention here is:   
      
       if ((block_id >= actblks) || (block_id < unblocks))   
      
   Most C programmers would write this as,   
      
       if (block_id >= actblks || block_id < unblocks)   
      
   And Kernighan and Pike would be fine with that.  It must be   
   noted that, throughout the rest of TPoP, they rarely   
   parenthesize as aggressively as they do in that one example.   
   For example, on page 98, in the discussion of building a CSV   
   file parser interface, they present a function called,   
   `advquoted` that contains this line of code:   
      
       if (pj] == '"' && p[++j] != '"') {   
   	...   
       }   
      
   (Note this doesn't just omit parenthesis, but also makes use of   
   the pre-increment operator _and_ boolean short-circuiting.)   
      
   Pike is famous for brevity; his 1989 document, "Notes on   
   Programming in C" is a model here:   
   http://www.literateprogramming.com/pikestyle.pdf   
      
   Even now, it's still an interesting read.  I like my own code   
   princples, as well, but of course, I'm biased:   
   https://pub.gajendra.net/2016/03/code_principles   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)