From: cross@spitfire.i.gajendra.net   
      
   In article <1081rg2$3njqo$3@dont-email.me>,   
   Simon Clubley   wrote:   
   >On 2025-08-18, Dan Cross  wrote:   
   >> In article <107nr15$18f8f$1@dont-email.me>,   
   >> Simon Clubley   wrote:   
   >>   
   >>>Unless it's explicit in the language syntax itself, and given that   
   >>>I write code in multiple languages, I have long written code that   
   >>>assumes implicit[*] short-circuiting is not available.   
   >>   
   >> Huh, interesting.  I suppose my take is that I have an   
   >> obligation to learn the idioms of a given language, if I am   
   >> writing code in that language, and this feels like one that is   
   >> useful to know about.   
   >>   
   >> To each their own, I suppose.   
   >   
   >I write simple to understand code, not clever code, even when the   
   >problem it is solving is complex or has a lot of functionality   
   >built into the problem.   
   >   
   >I've found it makes code more robust and easier for others to read,   
   >especially when they may not have the knowledge you have when you   
   >wrote the original code.   
      
   I'm curious how this expresses itself with respect to e.g. the   
   short-circuiting thing, though.  For instance, this might be   
   common in C:   
      
       struct something *p;   
       ...   
       if (p != NULL && p->ptr != NULL && something(*p->ptr)) {   
   	// Do something here.   
       }   
      
   This, of course, relies on short-circuiting to avoid   
   dereferncing either `p` or `*p->ptr` if either is NULL.  What   
   is the alternative?   
      
       if (p != NULL) {   
           if (p->ptr != NULL) {   
   	    if (something(*p->ptr)) {   
   		// Do something....   
   	    }   
           }   
       }   
      
   If I dare say so, this is strictly worse because the code is now   
   much more heavily indented.   
      
   Ken Thompson used to avoid things like this by writing such code   
   as:   
      
       if (p != NULL)   
       if (p->ptr != NULL)   
       if (something(p->ptr)) {   
           // Do something....   
       }   
      
   Which has a certain elegance to it, but automated code   
   formatters inevitably don't understand it (and at this point,   
   one really ought to be using an automated formatter whenever   
   possible).   
      
   AN alternative might be to extract the conditional and put it   
   into an auxiliary function, and use something similar to   
   Dijkstra's guarded commands:   
      
       void   
       maybe_do_something(struct something *p)   
       {   
           if (p == NULL)   
   	    return;   
   	if (p->ptr == NULL)   
   	    return;   
   	if (!something(*p->ptr))   
   	    return;   
   	// Now do something.   
       }   
      
   I would argue that this is better than the previous example, and   
   possibly on par with or better than the original: if nothing   
   else, it gives a name to the operation.  This is of course just   
   a contrived example, so the name here is meaningless, but one   
   hopes that in a real program a name with some semantic meaning   
   would be chosen.   
      
   If one is in a loop, judicious use of `continue` or `break`   
   might serve a similar purpose.   
      
   But all of this feels like quite a bit of ceremony to avoid a   
   common idiom in the language.   
      
   >I certainly don't feel the need to write job security code or some   
   >"macho" desire to write dense and hard to understand code to order   
   >to try and demonstrate to others just how "smart" I am.   
   >   
   >I am not saying you are doing that BTW, but I've seen enough code   
   >written by others which was clearly written with that mindset.   
      
   I understand, and largely agree.  There are programmers out   
   there who seem to delight in writing difficult to understand   
   code because they can, and because it provides them a vehicle   
   to demonstrate their intelligence.   
      
   >> Or, better yet, write less C and use safer languages.  :-D   
   >   
   >Unfortunately that's not really possible in many cases. I _strongly_   
   >wish a Wirth-style language had become the standard system integration   
   >and low-level language instead of C.   
      
   I confess I have a very soft spot for C: it was my first "real"   
   language.  In that sense, it reminds me of my first car: it was   
   a clunker, but it got me around.   
      
   That said, as much as I love C, I think it's best to avoid as   
   much as possible.  Realistically, _most_ programmers should be   
   working in managed, safe languages with clear semantics..   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)