From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   bill   wrote:   
   >On 8/29/2025 9:24 AM, Dan Cross wrote:   
   >> In article ,   
   >> bill   wrote:   
   >>> On 8/29/2025 9:11 AM, Dan Cross wrote:   
   >>>> In article <108k9de$1f69$1@dont-email.me>,   
   >>>> Simon Clubley   wrote:   
   >>>>> On 2025-08-25, Arne Vajhøj  wrote:   
   >>>>>> [snip]   
   >>>>>> But it is less obvious with other operators.   
   >>>>>>   
   >>>>>> Example:   
   >>>>>>   
   >>>>>> 4 == 4 == True   
   >>>>>>   
   >>>>>> Most languages (possible all exception Python) evaluate   
   >>>>>> that to True, because it is treated like:   
   >>>>>>   
   >>>>>> (4 == 4) == True   
   >>>>>>   
   >>>>>> But it is False in Python because it is treated like:   
   >>>>>>   
   >>>>>> (4 == 4) and (4 == True)   
   >>>>>>   
   >>>>>> Which feels less natural.   
   >>>>>   
   >>>>> And _this_ is an example of why Simon's policy of backets around   
   >>>>> everything makes it explicitly clear what was intended. :-)   
   >>>>   
   >>>> *At some expense for expert users.   
   >>>>   
   >>>> Which again, comes back to what I think is _actually_ the   
   >>>> interesting question: who do we write these programs for?   
   >>>   
   >>> Which is why I always preferred working for people with well defined   
   >>> local coding (and comment) standards.  And, yes, I have worked for both.   
   >>   
   >> Yup, though this doesn't _really_ address the question.   
   >>   
   >> But yes: having a locally agreed upon style for such things is a   
   >> _huge_ boon for maintainability, particularly across a large   
   >> codebase.  Sure, it's fun to belly up to the virtual bar and   
   >> debate the relative merits of different styles on USENET,   
   >> complete with contrived examples for or against different   
   >> conventions.  But the reality is that if one is consistent   
   >> within a code base, it doesn't really matter all that much;   
   >> competent programmers will absorb the rules in a matter of days   
   >> or weeks.   
   >>   
   >> The issue is that someone has to define the style and then   
   >> mandate its use, and it has to be enforced through rigorous   
   >> review and automated tooling.  Given a sufficiently large group   
   >> of users, not everyone is going to agree with every rule; the   
   >> trick is in getting them to follow those rules regardless.   
   >   
   >If you are an employee you either comply, find a new position   
   >or get fired.  No real trick at all.   
      
   Well, yes and no.   
      
   That is a very simple take, and it's true in some sense, but   
   omits the background work to make it happen.   
      
   Someone in a position of influence and authority needs to define   
   the style and everyone needs to agree to adopt it.  That does   
   not just happen; someone needs to make it happen.  And getting   
   to that point can be a challenge, particularly if you want it to   
   work at scale (MLOC or BLOC sized code bases) with many   
   programmers across different teams working on a shared source   
   repository simultaneously.   
      
   Moreover, in large codebases, someone off in a corner somewhere   
   might be writing code that doesn't get the same level of   
   scrutiny that other code gets; ensuring uniformity is more of a   
   social process (and thus hard) than an engineering process   
   (which is easy in comparison); automated tooling can help, but   
   it really needs to be part of the organizational culture.   
      
   Finally, the norms and expectations need to be documented, and   
   it needs to be not so onerous that it's de facto ignored.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)