Whitespace and bullying

[Martin Schwenke]

On Mon, 09 Apr 2018 10:41:07 +1200, Andrew Bartlett
<abartlet at samba.org> wrote:

> On Sat, 2018-04-07 at 20:32 +1000, Martin Schwenke wrote:
> > On Sat, 07 Apr 2018 20:18:29 +1200, Andrew Bartlett
> > <abartlet at samba.org> wrote:
> >   
> > > On Sat, 2018-04-07 at 16:44 +1000, Martin Schwenke wrote:  
>  [...]  
> > > We need to practice what we preach.  Many contributors (myself if you
> > > need a specific example) pattern far better by example of the code
> > > nearby than rule-books. 
> > > If the majority of our code doesn't comply with README.Coding then the
> > > rule shouldn't be in README.Coding.    
> > 
> > While I agree, I'm working hard to accomplish some particular goals.
> > Those goals don't include getting sidetracked by having to fix
> > coding standard violations in comments in code that I'm hoping to
> > remove.  I already feel over-committed and under pressure.  
> 
> I totally agree, but in a different way.  
> 
> The sheer amount of time and passion directed on this point, is why I'm
> calling bullshit on this rule, and why I say this isn't really about
> whitespace at all, but about power and control.
> 
> Asking developers, new or experienced, to match a whitespace guide that
> you can't see without filters and that much of our code doesn't honour
> on pain of public flagellation (but without our CI advising ahead of
> time) is just stupid.
> 
> We could perhaps save that for code going in without tests, which
> happens all the time and isn't commented on, or actually saying well
> done, like Andreas did.
> 
> If the whole team held to that positive review culture, or if those who
> continue to raise had made any effort to read the actual code to
> provide a balanced an productive comment, that would be a very
> different thing.  But code review by a significant number of team
> members, Volker in particular, has degenerated into the two categories
> of:
>  - 80 Columns
> and
>  - whitespace
> 
> Now, I've just make it personal above, and perhaps this is where this
> thread will totally derail.  

Let me make it impersonal again.  ;-)

Let's say we have a rule in README.Coding and that contributor X
doesn't set up their editor to help them adhere to that rule, they
produce changes that break that rule and those changes then make it
into the tree.

Then contributor Y, who does set up their editor to help them adhere to
that rule, opens a file that breaks the rule in their editor.  They see
distracting highlights throughout the code.  The only reasonable way
they can sanely work on the code is to make the code adhere to the
rule so that the highlights in their editor go away.

This is unfair.  The person who has set up their editor to help them
adhere to the rule spends their time fixing other people's breaches of
the rule.

Perhaps what we really need is an induction document that lists
technical things that can help team members adhere to the rules?

peace & happiness,
martin