9 ms·
I'm so happy that languages are settling more and more on heavy reformatter usage. I'd like to think it was triggered by Go and gofmt. Working on a team where e
by daenz 5y ago
I'm so happy that languages are settling more and more on heavy reformatter usage. I'd like to think it was triggered by Go and gofmt. Working on a team where each engineer has their own personal syntax is not fun.
- belval 5y agoIndeed, I don't like Black's style, but I prefer working in a Black codebase than one where everyone has their own preference. Having style guidelines in a team is also a great way to remove pointless debates when reviewing PRs.
- declnz 5y ago+1 ...which is why I wish Black allowed more configuration. A team can often agree on a set of styles. Every team on the Python planet agreeing... now that's much harder
- heavenlyblue 5y ago> A team can often agree on a set of styles. What for? Just to be clear even Django itself isn't obviously using a configuration, what makes your team so special they need this?
- harikb 5y ago> A team can often agree this usually just means new team members are stuck respecting the wishes of the old-timers
- david422 5y agoYea, but in this case the old timers have chosen Black so what's the difference?
- belval 5y agoI disagree on that though. By sticking to vanilla Black (no pun intended) you ensure that people joining your time will probably already be familiar with the style, you prevent strongly opinionated employees from pushing for changes in the linter config. Black is opinionated, so it skips the debate entirely. We just use Black, not black with 120 characters lines, just Black. To each their own I guess, but to me it just seems like pandora's box. Once you show that you are open to changes in the linting configuration, it makes the rules mutable and pretty much guarantees that at some point someone will say "how about we just change this one parameter in the linter", which will probably be agreed by the rest of the team, not because they actually agree but because they don't want to argue.
- spc476 5y agoYes, it's opinionated, but who's opinion got carved into stone?
- frosted-flakes 5y agoDoes it matter?
- spc476 5y agoWell, someone convinced the Python community that their coding standard should be the one coding standard.
- belval 5y agoThat does not really matter as long as the default are somewhat sensible. As far as I can tell Black's are. gofmt is also opiniated. Someone somewhere picked the defaults and maybe I disagree with those defaults, but in the grand scheme of things, all go code is more approachable because it all looks the same. That to me, is worth a lot more than having my favorite format be the one on top. EDIT: If you want to discuss the actual merits of Black, you can read their style page that actually explains every choice they made: https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html https://black.readthedocs.io/en/stable/the_black_code_style/...
- throwaway894345 5y agoMore configuration would allow for more fragmentation...
- pinkman68419 5y agoThe etymology of black is "any color you like, as long as it's black" [0]. The whole point is that it's _not_ configurable. [0] https://github.com/psf/black#readme https://github.com/psf/black#readme
- dumdumdumdum 5y agohttps://github.com/google/yapf https://github.com/google/yapf
- daenz 5y agoAgreed, and what's interesting is that despite all of those pointless style debates, there hasn't been much pushback on using reformatters (that I've seen). This tells me that the debates weren't really about "my style is objectively best" but more about "I'd like to use a consistent/predictable style (with preference to mine)."
- belval 5y agoQuite right, I have not met a lot of people that were actually strongly opinionated about their coding style. They simply did not want to use a tribal one that was not well defined that just added friction to the development process.
- kaesar14 5y agoGo and gofmt definitely pushed a lot of the momentum of the current wave but don't forget to give respect to Ruby / Rubocop where it's due, where the adage of Convention over Configurability has reigned supreme for decades.
- NegativeLatency 5y agoRubocop has about a thousand config options
- kaesar14 5y agoSure but the style guide standards exist and it's pretty rare for a Ruby application to stray from them (from my experience at a multi-billion dollar public company Ruby shop)
- MisterTea 5y ago> Working on a team where each engineer has their own personal syntax is not fun. Why did your team not implement a style guide? Not following style is not working as a team and this needs to be addressed.
- daenz 5y agoOn this particular small team, there was no style guide, and nobody could agree on what would go in it. It was dysfunctional.
- acdha 5y agoStyle guides are a notorious time-sink where people will spend enormous amounts of time debating various conventions without that being linked to measurable benefits. One of the big problems here is that people notoriously conflate “familiar” with “better” and you rarely run the counter-experiment showing that after a couple weeks everyone would be familiar with any of the serious proposals. The advantage of a tool like Black is that it avoids that constant bikeshedding and the fact that it actually does the work for you puts the conversation in a different light because the option which is the least work is just letting Black format the code. Whatever you pick for style, you really want automatic formatting to avoid it seeming like a chore.
- MisterTea 5y ago> Style guides are a notorious time-sink where people will spend enormous amounts of time debating various conventions without that being linked to measurable benefits. It feels like we're trying to justify the continued employment of uncooperative, contrarian egoists. Pick a style and use it or they can go find another job to waste time debating nonsense.
- BeFlatXIII 5y agoOnce they're all fired, there will be no one left to do the work.
- acdha 5y ago