From: cross@spitfire.i.gajendra.net   
      
   In article <68b2549f$0$718$14726298@news.sunsite.dk>,   
   Arne Vajhøj   wrote:   
   >On 8/29/2025 9:24 AM, Dan Cross wrote:   
   >> In article ,   
   >> bill   wrote:   
   >>> 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.   
   >   
   >Yes.   
   >   
   >> 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.   
   >   
   >It does not take that much to get coding conventions   
   >followed.   
      
   Statements like this beg the question, what is the largest   
   project you have worked on, and with how many other engineers?   
   I am asking sincerely, by the way; that's not a dig.   
      
   I once worked in a, at the time, 2BLOC monorepo with ca O(10^5)   
   programmers working in it concurrently in ~20 engineering   
   offices spread across the globe.   
      
   A tiny subproject within that was ~1MLOC split between about 500   
   KLOC in C++, and the other 500 KLOC in Common Lisp; HC was   
   around 20 FTEs mostly in a single office.   
      
   The local style guide mandated that the maximum line lenth in   
   Lisp was 100 characters; I counted and estimated that at least   
   20% of lines had more than 110 characters.   
      
   That project came through an acquisition, and the code was   
   inherited.  On the other hand, the rest of the organization had   
   _very_ rigorous code style rules for various languages (five   
   officially supported languages, and a dozen or so other,   
   unofficially supported languages) and gated integration   
   verifying compliance with those rules through both review and   
   automatic tooling.  In that code base, style violations were   
   exceedingly rare.   
      
   Incidentally, in the Lisp project, there were no automated   
   unit-level tests, as the team had bought completely into the   
   myth of incremental, REPL-centric development.  Which meant that   
   every single time I made a change in that code I found an   
   existing bug.  Every. Single. Time.  There was a large body of   
   integration tests, but running the test suite took about 3 hours   
   on a very beefy workstation, so reasonably a programmer could   
   get two integration runs a day.   
      
   The rest of the organization, in contrast, had a strong culture   
   of automated batch unit testing, and successful CI was required   
   for commiting a change.  Tooling existed that could compute the   
   transitive closure of the dependency graph for any given change,   
   so all relevant tests could be run; integration was blocked if   
   any failed.   
      
   Guess which side of the house had a lower overall defect rate   
   and higher developer velocity?   
      
   But this is the difference between making something a strong   
   part of the organization's cultural norms and supporting it with   
   tooling and just wishing the problem away.   
      
   >If >5% of code is reviewed and not following coding   
   >convention get flagged and the guilty get asked to fix   
   >the code *and* other code that has same problem, then   
   >in a few months everyone is following. The risk of   
   >non compliance eventually being detected and the hassle   
   >of doing the fixes makes it easier to do the right   
   >thing the first time.   
      
   That's cute, until managers step in and tell you to igore all of   
   that, because they've got a customer breathing down their neck   
   to get a feature they need into production.  It also shows a   
   distinct lack of respect for your engineers.   
      
   As part of the build process for that Lisp project I mentioned,   
   an automatic linter ran that flagged style violations.  There   
   were so many that the output was so voluminous that it was   
   universally ignored.   
      
   The point is that you really need to inculctate respect for the   
   value that comes from rigorous adherence to those rules, and   
   support it with tooling so that they are easy to comply with   
   (and there are meaningful consequences for igoring them---like   
   your change just can't be submitted).  Otherwise, they will just   
   be ignored, and attempts to force them by making people do a   
   bunch of grunt work if they're caught violating one will   
   backfire.   
      
   The "culture of fear" approach that you and Bill both seem to be   
   advocating simply does not scale, especially once it runs   
   headlong into the reality of the business considerations that   
   come with  taking engineer time to do a bunch of busy work to   
   fix something that somebody else did.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)