Comment by NeutralCrane | Hacker News Reader

Comment by NeutralCrane | Hacker News Reader

Parent Full thread

This seems like a strange hill to die on. Linters don’t consume energy, that’s the entire point. They get everyone on the same standard so that no energy is wasted by anyone on having to discuss, debate, and implement these standards. And yes, there are instances where someone’s non-standard coding style is not a problem. But there are instances where it absolutely can be, and these tools help there.

I’m also not sure I understand the “ My place used pylint, flake8, black, ruff -- with hundreds of commits on every change”. These tools don’t add extra commits. You run them prior to your PR, get them aligned with the linting, and then commit the change you were already going to make. Thats 0 extra commits.

For someone ultimately arguing that there is too much effort spent on people’s coding styles, you are spending a lot of effort arguing about people’s coding styles. These tools are some of the most set it and forget it things around.

> These tools don’t add extra commits.

When you replace tool x with tool y, you need to fix your code, because these tools do not agree on what your code should look like, and what was acceptable for tool x simply isn't for tool y.

One of these changes I mentioned brought a massive reformatting of all code base, as the new tool failed 'import' statements unless they were in alphabetical order.

Sounds like the issue is not the tools themselves, but that the project management / stewardship allows someone to replace tools willy-nilly leaving others to pay the cost of migration?

At $WORK we have "code guardians" whose responsibility is do to this kind of migrations strategically in the background. The intent is that most other developers should not need to do any (or very little) extra work beyond the task they are actively working on.

The linked article says that ruff now has 413 default rules -- instead of 59 previously. Do I understand it right that all the projects that were using ruff were 100% conformant to 59 rules yesterday but likely not conformant to 413 rules today, which will cause breakage all across the board? Likely immediately followed by a swarm of pull requests all formatting their code in conformance to whatever these new (413-59) rules are?

There's no "tool replacement" going on here.

Well, that's the danger of using software without version pinning.

Also, usually tools like Ruff can be configured to enable/disable project-specific formatting rules (via a config file), allowing you to suppress the defaults you disagree with, or whose consequence you don't want to deal with _right now_. Some tools might even support suppressing specific rules per-file, so you can migrate codebase over time instead of in one go.

Having a config that explicitly defines the rules enforced in the project is really useful, and perhaps even crucial the bigger the project grows.

The options you suggest seem to be either (a) feed the bot now (halt development and reformat all code) or (b) under-pin/suppress and feed the bot later, probably dealing with people adding more non-conformant code to already-reformatted files.

You will probably have to do it all over again when these guys release even newer and shinier 0.17.0, with even more rules.

I can't understand how the option of not feeding the bot eludes people.

If you change the formatter for your project then yes, you have a single commit where you reformat your project and then commit this.

A single commit after a tool change. I don't see the problem.

Reply on news.ycombinator.com