7 ms·
> From what I've seen so far, people love debating code style. In my experience with people who seemed to confirm this, the opposite turned out to be true. I s
by eyelidlessness 3y ago
> From what I've seen so far, people love debating code style.
In my experience with people who seemed to confirm this, the opposite turned out to be true. I spent an inordinate amount of time configuring linting and formatting to suit their tastes, to minimize any formatting subjectivity in code review. Their reviews got a lot more substantive and valuable pretty much immediately because their formatting concerns were evidently close enough to solved that they could pay attention to what the code actually did.
I’ve had similar success adopting formatting that no one likes just because it’s opinionated and no one gets to dispute it because they couldn’t if they wanted to without diverting resources to a new tool. Now we’re all unhappy with the formatting and still happy to be reviewing actual substance.
When the bad formatting gets in the way, it’s trivial to ask the question “is this just a whitespace change?” and everyone groans for a second, agrees that it is, and gets on with life.
And when there’s any remaining style considerations (oh you like, or don’t like, reduce?) that’s a much smaller space of style concerns to negotiate and settle.
- Pannoniae 3y agoI think this is just accommodating anti-social behaviour, IMO. I think the correct choice of action is simply rooting the problem out by penalising comments about style on code review, so they focus on the substance of the code instead. Yes, this will require a period of uncomfortability while everyone gets used to each other's varied code styles, but it promotes a much more healthier atmosphere than the "suck it up" approach of unifying all code. That doesn't solve the problem, that just masks it by putting the code through a shredder so style gets lost.
- bluGill 3y agoA consistent style is useful. It doesn't matter much what it is, but consistency means you can jump into unfamiliar code and not get misled by a different style that makes some block not appear how it actually functions.
- eyelidlessness 3y agoI have a ton of code style preferences that I’m thrilled to put on the back burner to accomplish really much more important things with my team. I can express my individuality and let my whitespace and brace freak flag fly on personal projects, and I can even have more energy to get those adopted into core work if I want to, because my daily work isn’t burdened by formatting preference taking away from much more important concerns like whether the thing actually works, has acceptable performance and usability and accessibility characteristics, and can be maintained on a continuous basis. It’s not that anyone else has felt stifled by this either. Everyone everyone contributing has welcomed the automated formatting dictator. We’ve all felt the benefit of not focusing review on stuff that doesn’t impact users. If you really want to express yourself in code formatting, go wild on your own time and enjoy the free time you have for it by not putting it in the middle of otherwise meaningful work.