Comment by jbvlkt
2 days ago
Those tools actually save team energy. Without them any programmer has different opinion on formating, code quality, what is readable etc. You can discuss it endlesly or you can just use ruff.
2 days ago
Those tools actually save team energy. Without them any programmer has different opinion on formating, code quality, what is readable etc. You can discuss it endlesly or you can just use ruff.
We can replace the endless and useless discussion on how to format code with an endless and useless discussion on what linting tool to use.
Another option would be to leave both topics alone and go on with our lives, improving the product, fixing bugs, implementing new features, and generally giving customers a better product and shareholders more value, while respectfully agreeing to disagree on the issues of style.
People tend to use tools set up in CICD and/or precommit. Without rules everyone uses their tool and is unwilling to compromise. Even if they are willing it is hard to setup tools to do exactly what you want. Default configuration is always the way.
So to the practical question: what we're gonna do today in CICD and/or precommit? "Default configuration is always the way" but which one: `ruff<0.16.0` or `ruff=0.16.0`?
5 replies →
> We can replace the endless and useless discussion on how to format code with an endless and useless discussion on what linting tool to use.
That is why gofmt is so great. As the saying goes: gofmt’s style is nobody’s favorite, yet gofmt is everybody’s favorite.
I have never discussed code formatting and drive-by changes more than in projects with auto formatters.
Why though? I've yet to come across an auto formatter that formats things the way I personally like. But that's fine. I do whatever the hell I want until I'm ready to open a PR, then bang it through the auto formatter. And you know what? I can also go the other direction and run a home-brew auto formatter to reshape things the way I personally want on my local machine.
I'm not sure why, but apparently my experience is unwelcome enough to be downvoted. Drive by changes are really annoying, IMO, and as the GP shows, the formatting tool outcome differs. So there are many "valid" versions of the same program logic. You have therefore not do what these formatters pretend to do, namely take this variable out of the equation. Rather, the wrong auto format can look much worse than the original.
I'm not sure why people felt formatters were necessary. but now they're part of the zeitgeist and there is no going back.
Gods forbid I talk to people I work with, learn their preferences, and figure out the way we can accommodate each other. Sounds like such a waste of energy. It’s so much better if we all acquiesce to the preferences of some people neither of works with!
How does that work when hundreds of people are working on a project, with a few new people joining every week?
It boggles me that anyone would argue against standardization, or believe that “just get hundreds of people to agree today and tomorrow and every future day” is a better solution.
In my own experience it works pretty well. In fact better than the autoformatters.
It was essentially not an issue. Sometimes I’d grumble about someone, but it would never get in my way the way black or ruff would regularly.
You can still talk to them about more important problems than placement of collons and closing bracket.
Actually the aesthetic preferences of people I regularly work with are important to me.
1 reply →