[dead]
Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
61–70 of 247 posts
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#62I wish Go had something like Ruff! A lot of languages are getting amazing tool but Go has a very fragmented ecosystem with a lot of tools but none of them feel as high quality has the likes of Ruff, Oxc, Biome or even PHP's Mago
It does and it is even better. It is called the Go Analysis Framework ( https://pkg.go.dev/golang.org/x/tools/go/analysis ). It is fairly new so not well known but it is what powers go fix and go vet under the hood. And I believe the Go team is currently working on making it possible for module authors to easily describe their own custom analysis passes that would run automatically when running go fix. It is extremel…
https://news.ycombinator.com/item?id=49057398
Let's spread the word
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#63Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#64The amount of fascination that people have with these "grammar nazi" bots -- some of them implementing completely arbitrary "rules" and some of them disagreeing with others on what "good" Python code should look like -- doesn't stop to amaze me. Here's "bad" code: important_numbers = { 'x': 3, 'y': 42, # Answer to the Ultimate Question! 'z': 2 } Here's what "good" code should look like: important_numbers = {"x": 3, "…
It’s because you forgot a comma after the last item. If you had kept that the items wouldn’t have been compacted (at least in black, I’ve stopped linking my code because it breaks intends of formatting more often than it helps)
Sorry, but I did not "forg[e]t a comma after the last item". I intentionally did not put a comma there. The list of the "important numbers" in my example is already complete and perfect, and is not supposed to ever change. I wanted to emphasise this fact by specifically omitting the comma there, in the hope that intelligent people in the future would get this message exactly as I intended for it to be.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#65Earlier quoted context omitted.
Waiting patiently for the other person to produce a post hoc rationalization about why everybody’s code looking different is in fact a good thing
Can you not read code if it uses single vs double quotes?
You are not making the strongest point by using a relatively subjective rule like that. It includes indentation, how to structure functions and the parameters and many more that in sum make it very easy to jump between projects (Internal company projects, dependencies, other open source projects) without ever getting used to a new style. This makes reading and contributing very easy.
Compare that with other languages where you need to load a different set of prettier rules, code formatting tools and follow contribution guidelines on how things should look like depending on the opinion of the maintainers.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#66The amount of fascination that people have with these "grammar nazi" bots -- some of them implementing completely arbitrary "rules" and some of them disagreeing with others on what "good" Python code should look like -- doesn't stop to amaze me. Here's "bad" code: important_numbers = { 'x': 3, 'y': 42, # Answer to the Ultimate Question! 'z': 2 } Here's what "good" code should look like: important_numbers = {"x": 3, "…
The actual rules are less important, only the consistency of applying them is. I find that people who argue against automatic linting and formatting tend to be the same that would argue incessantly about style. So much wasted energy, I want none of that. Also, in your example above, if you put the comment on the line _above_ instead of inline the formatter will most likely do the right thing.
"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines."
-- Ralph Waldo Emerson
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#67I find it somehow interesting that a tool for Python is written in Rust.
Interesting but not surprising in an application where speed matters.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#68If you listen closely you can hear the thousands of CI jobs that just pull latest UV failing all at once.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#69Earlier quoted context omitted.
Maybe it's just me, but getting overrun with "413 x potential warnings" hardly sounds useful :) Great for greenfield, less so for existing projects. Although nowadays, fire up your agent with "/goal work through and address all lint warnings by fixing the code according to XYZ" and leave it alone for a couple of hours and I guess it's no longer an issue... Don't get me wrong, the new level of details coming from Ruff…
> uv run ruff check --fix Generally gets you 90% there.
In reality it got me 30% there.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#70The amount of fascination that people have with these "grammar nazi" bots -- some of them implementing completely arbitrary "rules" and some of them disagreeing with others on what "good" Python code should look like -- doesn't stop to amaze me. Here's "bad" code: important_numbers = { 'x': 3, 'y': 42, # Answer to the Ultimate Question! 'z': 2 } Here's what "good" code should look like: important_numbers = {"x": 3, "…
You may do as you like in your projects. You might even find you can make a formatter enforce that rule which is apparently important to you.
But one thing I bring to every team is this: “I don’t want to look at a file and say that is Tom’s code or that is your code. What I want to see is [project name] code.”