Live data from Hacker News

Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

astral.sh

181–190 of 247 posts

Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

#181
post #125

Earlier quoted context omitted.

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 sur…

> 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.

Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

#182
post #37
post #20

Earlier quoted context omitted.

In my previous place, discussions on coding style were forbidden in PRs. It worked just fine. Edit: one could also use single or double quotes in strings, and it didn't anger the grammar nazi bots as there were none.

Which gets rid of the discussion, but not the problem coding style rules are supposed to fix: Code looks the same, regardless of who wrote it. That's the whole point of code style guidelines like that as there's no functional reason for them. That's why I like Go, every piece of code looks the same, there's one default enforced linter and this discussion (or discussion if discussion should be allowed or prohibited) d…

Is that really a problem that needs solving though? The easiest way to not spend time bikeshedding is to just not bikeshed. Don't make guidelines. Don't run tools to check them. Don't comment on them in PRs. None of it matters.

Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

#183
post #47
post #26

Earlier quoted context omitted.

Go has a good start for that, but It's not enough for me. Gofmt is a great idea but it isn't strict enough for my taste. Go does not have any first party static analyzers, closest is Staticcheck which is even sponsored by Google themselves

go vet, plus all the ones in gopls?

I don't believe you can add custom analyzers to `go vet`, which arguably rules it out.

But it is extremely simple to make a custom vet-like tool, because it's a trivial binary wrapper around the analysis framework, which is first-party (though it's structurally pretty limited by design, and won't handle all linting needs): https://cs.opensource.google/go/go/+/refs/tags/go1.26.5:src/...

Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

#184
post #37
post #20

Earlier quoted context omitted.

In my previous place, discussions on coding style were forbidden in PRs. It worked just fine. Edit: one could also use single or double quotes in strings, and it didn't anger the grammar nazi bots as there were none.

Which gets rid of the discussion, but not the problem coding style rules are supposed to fix: Code looks the same, regardless of who wrote it. That's the whole point of code style guidelines like that as there's no functional reason for them. That's why I like Go, every piece of code looks the same, there's one default enforced linter and this discussion (or discussion if discussion should be allowed or prohibited) d…

The value isn't just in the lack of discussion, but in amplifying the signal to noise ratio of diffs. with ruff or gofmt or whatever, it’s pretty much guaranteed that a change of code is an intentional part of the proposed change. with multiple authors with variable code styles touching the same project, there is a much higher chance of a diff containing lines that preserve semantics but change the code.

Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

#185
post #90

Earlier quoted context omitted.

Okay, so if the battles are won why do I have to care? What is the point of having so many strict, enforced style rules if your exemplar has already been long dealt with?

One war was won bro, there are many more. Pretend they don’t exist as much as you’d like, tell everyone their lived experience is wrong, that the tools arose from delusion and not any real world need, and that they benefit no one. I’ll keep using them though, and never suffer from someone writing typescript with 4 spaces, leading commas, and no semicolons again.

I'm not saying that lived experiences are wrong, I'm saying that I don't believe that these problems would exist under the current software engineering culture to the degree that people seem to insist upon.

Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

#186
post #37

Earlier quoted context omitted.

Which gets rid of the discussion, but not the problem coding style rules are supposed to fix: Code looks the same, regardless of who wrote it. That's the whole point of code style guidelines like that as there's no functional reason for them. That's why I like Go, every piece of code looks the same, there's one default enforced linter and this discussion (or discussion if discussion should be allowed or prohibited) d…

Is that really a problem that needs solving though? The easiest way to not spend time bikeshedding is to just not bikeshed. Don't make guidelines. Don't run tools to check them. Don't comment on them in PRs. None of it matters.

Historically, yes. At some point, one person who likes to work with narrow terminal windows gets fed up with long lines and starts reformatting stuff as they go. Another person with a widescreen editor hates looking at code clustered around the left edge of the screen gets fed up and starts reformatting stuff as they go. It's just a mess. You end up with PRs where it's hard to see the 3 things that changed because it contains 200 lines of "my IDE would prefer to format things this way instead".

I have never seen this not happen, barring using autoformatters. I think Go and Rust have had great success avoiding all these dumb arguments by having built-in opinionated formatters from nearly the beginning.

Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

#187
post #95

Earlier quoted context omitted.

At work? School isn't really representative.

Oh, absolutely. I started writing Python professionally in 2010. Whenever a new group of people started working on a Python project, one of the first things they had to decide was tabs versus spaces. Everyone would begin by saying that the question was unimportant and silly, but then immediately add a “but” followed by a detailed justification of their personal preference. That would lead to people spending two full…

I think that tabs vs spaces is a rather extreme example because it has unexpected parser semantics - that is, it's not a style choice. So I don't think it's actually relevant to a conversation about conventions/ style.

Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

#188
post #112

Earlier quoted context omitted.

The one day, your chef leaves, the food goes to shit and productivity/output/morale drops. When the new chef arrives, then everyone has to relearn everything. Software shouldn't be bespoke and "artisan".

And here's where this abstraction breaks: when a programmer leaves, their code is not going anywhere. The bigger problem is this: you want me to be a cog wheel, but I want to be an artist.

> The bigger problem is this: you want me to be a cog wheel, but I want to be an artist.

Well, that's the ball game then. This isn't the industry to be an artist in, especially post-AI.

Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

#189
post #108

Every new single piece of software calls itself “extremely fast”, “blazingly fast”, it gets tiring.

Broadly you have a point. In this case I would expect a Rust-based Python linter to run significantly faster than one writen in Python itself (e.g., pylint).

Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59

#190
post #162

Earlier quoted context omitted.

your argument is about formatting and clearly you feel strongly about it. this is the difference between the atheist who strongly believes nobody should believe and the atheist who isn't interested and doesn't care

Yeah, I'm in the "not interested" and "don't care" camp, with the addition of "please don't come at me with your bots who would tell me what to believe and what not to believe". If someone wants to use a linter, I have no problem with that. I don't, and I don't want others forcing one on me, especially so as most of its "results" are straight in "this doesn't matter either way" category (in my example: two spaces ins…

unwillingness to go with the flow without big arguments is what I'm talking about
Post reply on HN