I updated a ~3k line Python project with this the other day. I was using v0.15.x beforehand. It didn't take too long and the new rules do improve code quality. It caught quite a few things previous versions didn't.
The 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, "y": 42, "z": 2} # Answer to the Ultimate Question!
Which completely misses the writer's intent. But did you notice that there are two spaces before the pound now? Also, the quotes are now double because apparently it's somehow more kosher! So much improvement!
The actual problems in the code I work with are not the spaces at the end of line or imports in non-alphabetic order, it's the 10-line list comprehensions that are so long that they're impossible for me to parse. None of these tools catch that. My place used pylint, flake8, black, ruff -- with hundreds of commits on every change. All that energy could be better spent elsewhere.
The point of the "grammar nazi" bots is to focus on the actual problems: if a bot is deciding about linting, you don't have to waste brain power to discuss it in PRs.
It is what it is, everyone gets the same, shut up and work on what matters.
I'm surprised you consider it a lot of energy spent, I tend not to spend any on this, it just runs automatically on my code and I drop out of pretty much every discussions about linting as it's good enough with automated tools.
I also used to work in places where there was no such tools, and there I had to actually spend time discussing and thinking about linting.
Using a consistent string delimiter has value: if you search for ['foo'] you will find all instances of the string foo. With inconsistent delimiters, you better have a single canonical 'foo' in your project or you're going to run into problems.
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) doesn't even cross anyones mind.
My argument is more to the tune of "everybody’s code looking slightly different is not a problem in practice as long as I can read and understand it."
However since you've asked so nicely here you go: everybody’s code looking different is because all humans are different. It's what makes us human. I am very serious about my craftsmanship, and I bring my "humanity" to it: sometimes I include a cultural reference (as in the example above), or an internal joke in the name of a (very long) variable, or vent my frustration in a comment.
My first ten years of writing Python were uneventful; nobody commented about my style and I never commented about others'. With the advent of grammar nazi bots, everyone is supposed to now please them by writing completely bland code, which in my opinion degrades me from a craftsman to a code-monkey. This is dehumanising, in a certain sense.
I can - in fact, I have to, a lot more than I'd like - when someone makes changes with different code style settings in their IDE or tooling, and that affects unrelated parts of the code, and suddenly the PR contains tons of code that just looks subtly different but still does the same thing.
If sieving the spam from ham in code reviews is your thing, go have fun.
I personally prefer code that is automatically and unconditionally kept in the exact same shape, preserving only the intended changes to stop the team from wasting time on formatting or reviewing.
That seems like a problem caused by an autoformatted, not solved by one. Obviously having reviewable commits is a reasonable expectation but that doesn't seem like a justification at all.
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.
I've never found this to be the case having jumped companies a fair bit. I can switch programming languages easily enough, surely I can handle formatting.
Even better: if someone feels like the syntax must be different, they can pick it up at a centralized repository with more people that specialize in syntax.
Afterwards it will affect production code everywhere on the planet. :)
I've never seen this debate take place outside of internet forums, almost always as a joke. It's been about 15 years since I even remember it coming up much as a joke, frankly.
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?
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.
> this seems like a made up problem or something that predates my career
I can believe the latter, and I can assure you this was a Big Deal back in the day. There's a reason Go ships with gofmt, and gofmt was somewhat revolutionary for being a built-in "you gotta do it like this" back in the day.
These used to happen all the time. In one (otherwise great) programming course in university you would even get points subtracted if you did not follow the lecturer's preferred style.
(I think that in their case it was partially because uniformity made correcting faster.)
Silicon Valley (the TV show) memed about it with its tabs vs spaces bit. It used to be a thing for sure. It has been a good 10 or 15 years since I had such a discussion. Automated linting and formatting tools largely killed it in my experience.
I think the culture has just shifted. I haven't even sniffed a whiff these conversations since roughly 15 years ago. I've never, ever seen them at work.
I also never have these conversations at work…because every repo uses a linter and the engineers are mature enough to recognize most of these debates as bikeshedding. Every once in a while someone will suggest turning on or enabling a new custom rule with some justification and there is a brief discussion and it is enabled or not. Outside of work in a consulting gig I didn’t have a linter in the codebase and the owner brought on a new engineer, he wrote if else statements all on one line no matter how long they were and removed spaces everywhere because he thought shorter code was better. He balked hard at any feedback about code style and I was told I couldn’t enforce code style or install a linter. I think you will surprised how much you care if someone with a truly weird style starts putting it in your codebase, I always told myself I didn’t before this. After more dumb waste of time clashes like that I quit the project. Now even personal projects get a linter :).
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.
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.
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.
The trailing comma rule is to avoid errors when devs copy/paste a line or dump a new line at the end. This matters particularly for arrays in languages with implicit string concatenation, where the missing comma won't trigger a compile error.
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.
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.”
It's funny to see this comment about Python, which was designed to be a style North Korea. Maybe in a decade we'll see a Go linter and have a good laugh at that.
I 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 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 extremely easy to define your own analysis.Analyzer struct that describes your own static analysis pass. You get access to all sorts of useful information such as the AST, types, even SSA info and you can even compose the information between analyzers. Then you can easily compile it into a binary and run it by passing that binary to go fix with a command line flag. The go toolchain itself handles all the complex caching logic so that your analyzers run fast.
Since it is made by the go team itself and part of the toolchain it should slowly become the unified standard you are looking for. So hopefully golangci-lint and others should eventually all unify under this framework.
You can easily give it a go by telling some AI agent to write some Go Analysis analyzers and telling them to drive them with go fix. My Go projects tend to accumulate a bunch of these to enforce all sorts of rules deterministically and automatically instead of some imprecise markdown file.
That sounds amazing! I do hope golangci-lint and the likes pick it up, I'm a big fan of the strict by default approach that Ruff and other linters have taken.
Gofmt is great but it's still not very strict, the amount of times my colleagues have argued about formatting in Go is still too great, stuff like consts, types, funcs, methods order, struct initialziation newlines and other details that do matter, but they should be decided one and then applied everywhere like that.
Yeah, that's how much Astral changed python. UV and Ruff are amazing tools.
Go can get there, but like I said, I think everyone is building some partial tools that solve some problems, but there is not that one player building that one great tool.
I've been using golangci-lint for years, it's okay but it's slow even with a cache, as soon as you have good amount of lints enabled your ci can suddendly take minutes.
That's not the fault of golangci-lint, it's just the concept of bringing together a bunch of different linters and keeping it fast is impossible. And the configuration is a bit wild too, because every linter obviously has their own decisions on how it wants to be configured.
I’m not entirely sure what you mean by a fragmented ecosystem? Go has first-party formatting and linting and the language is deliberately restricted to ensure it is written in a certain way, even when written by complete novices.
Compare that to Python or TypeScript which are Wild West languages without opinionated first-party tooling, and it’s clear why Ruff/Biome feel great.
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
What? I feel go has one of the best language tooling out there without requiring a bully ide to do stuff. golangci-lint is quite comprehensive. What do you miss otherwise?
(Honestly go's distributing itself has covered a lot of it)
golangci-lint is good, but you have to glue together a bunch of linters, and it adds up. You can easily get runtimes of several minutes, there are caches etc but the main problem is that golangci-lint doesn't own the lints, so it will never be as fast as something like Ruff.
I have actually tried. But I'm not very knowledgable in the area, so it's more LLM slop than my good ideas. And I'm not sure I have the energy and passion to maintain it long term.
It's definitely possible, if Google would put like one or two smart minds on the problem full time they could easily solve this problem and make the ecosystem so much stronger. But I'm guessing they already have something like this in-house and no interest in open sourcing it.
Default on lint is good for agent fleets. fwiw, I watched one agent "fix" an unfamiliar rule by deleting the test; perfect compliance, tiny misunderstanding.
This is great news! With the advent of agentic coding, strong linting is more important than ever. What I'd really like to see is forbidigo for more languages.
100% agree, I am upgrading my projects now. And yet, I have mixed feelings about this. I like to think that when I (was) writing code myself, I applied a great deal of intuition to decide when to skip or ignore some rule. On the hand, I also saw projects were developers where using pylint with most rules enabled and I have to say the code was not better - on the contrary it had plenty of hacks to make pylint happy at the cost of illegible code.
Not unlike that experience, I also saw coding agents spend lots of tokens trying to fix a benign issue, as well as doing the opposite - like disabling the tests !!! when they don't pass. :facepalm:
I grew to trust AI results in terms of overall correctness, but I still have hard time trusting their *judgement* on the *code quality*.
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 is much appreciated and a good thing :)
On the 0.16.0 release it was more like 10% autofixable on the codebases I maintain. One of them had 100+ unfixable errors across less than 10k lines of code and tests in total. Previous ruff version labeled it perfectly clean on format and check with default settings.
Good thing we have LLM:s that can do the tedious work of checking each case and applying local annotations or updating the config globally! If I was stuck doing this manually, I would have just gotten rid of ruff and went back to black+pylint.
I don't think they were trying to say "No, ruff doesn't work at all", more that "gets you 90% there" might have been an over-exaggeration, or very codebase-specific number and really, YMMV.
It's the same for JavaScript. Rust is the better language (especially for large projects like these), but sometimes you don't have a choice but to use Python or JS/TS.
I sorta kinda get why `ty` is pre v1.0.0 -- it's a typechecker that doesn't check a huge number of types. But what are we waiting for with `ruff`? Surely it's eaten whatever the old options were (black? maybe a few takes on py+lint?) by now many times over, and is even more dominant than `uv`.
I run this program hundreds of times a day so I'm generally excited for new features, but I guess the OAI acquisition has made me ornery when it comes to these folks. Apologies to kindly nerds who made this release happen, and congrats <3
Yes but the question is why Ruff has not released v1 yet. They’re clearly used in production and the entire purpose of v0.x is to signal a project is early in development and is expected to have coarse edges.
Here's a few commits of changes:
(A whole bunch of manual changes based on its suggestions) https://github.com/nickjj/plutus/commit/9af66d31f98bef841588...
(Re-enable line length) https://github.com/nickjj/plutus/commit/21789f89bbcee37913c1...
(Force _ prefix for unused variables) https://github.com/nickjj/plutus/commit/a272c77b932e1c78558a...
(Auto-corrected by Ruff) https://github.com/nickjj/plutus/commit/6fe69cf88385ebdf9b8c...
Here's "bad" code:
Here's what "good" code should look like: Which completely misses the writer's intent. But did you notice that there are two spaces before the pound now? Also, the quotes are now double because apparently it's somehow more kosher! So much improvement!The actual problems in the code I work with are not the spaces at the end of line or imports in non-alphabetic order, it's the 10-line list comprehensions that are so long that they're impossible for me to parse. None of these tools catch that. My place used pylint, flake8, black, ruff -- with hundreds of commits on every change. All that energy could be better spent elsewhere.
It is what it is, everyone gets the same, shut up and work on what matters.
I'm surprised you consider it a lot of energy spent, I tend not to spend any on this, it just runs automatically on my code and I drop out of pretty much every discussions about linting as it's good enough with automated tools.
I also used to work in places where there was no such tools, and there I had to actually spend time discussing and thinking about linting.
Edit: one could also use single or double quotes in strings, and it didn't anger the grammar nazi bots as there were none.
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) doesn't even cross anyones mind.
However since you've asked so nicely here you go: everybody’s code looking different is because all humans are different. It's what makes us human. I am very serious about my craftsmanship, and I bring my "humanity" to it: sometimes I include a cultural reference (as in the example above), or an internal joke in the name of a (very long) variable, or vent my frustration in a comment.
My first ten years of writing Python were uneventful; nobody commented about my style and I never commented about others'. With the advent of grammar nazi bots, everyone is supposed to now please them by writing completely bland code, which in my opinion degrades me from a craftsman to a code-monkey. This is dehumanising, in a certain sense.
If sieving the spam from ham in code reviews is your thing, go have fun.
I personally prefer code that is automatically and unconditionally kept in the exact same shape, preserving only the intended changes to stop the team from wasting time on formatting or reviewing.
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.
Afterwards it will affect production code everywhere on the planet. :)
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 can believe the latter, and I can assure you this was a Big Deal back in the day. There's a reason Go ships with gofmt, and gofmt was somewhat revolutionary for being a built-in "you gotta do it like this" back in the day.
(I think that in their case it was partially because uniformity made correcting faster.)
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.
That is why gofmt is so great. As the saying goes: gofmt’s style is nobody’s favorite, yet gofmt is everybody’s favorite.
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.
Taking that as a reason to not have those rules in the first place seems like a logical fallacy that intelligent people should not make.
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.
-- Ralph Waldo Emerson
By the way, you have the exact energy of someone who would argue about code style: a prima donna who quotes Emerson when confronted with disagreement.
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.”
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 extremely easy to define your own analysis.Analyzer struct that describes your own static analysis pass. You get access to all sorts of useful information such as the AST, types, even SSA info and you can even compose the information between analyzers. Then you can easily compile it into a binary and run it by passing that binary to go fix with a command line flag. The go toolchain itself handles all the complex caching logic so that your analyzers run fast.
Since it is made by the go team itself and part of the toolchain it should slowly become the unified standard you are looking for. So hopefully golangci-lint and others should eventually all unify under this framework.
You can easily give it a go by telling some AI agent to write some Go Analysis analyzers and telling them to drive them with go fix. My Go projects tend to accumulate a bunch of these to enforce all sorts of rules deterministically and automatically instead of some imprecise markdown file.
Let's spread the word
Gofmt is great but it's still not very strict, the amount of times my colleagues have argued about formatting in Go is still too great, stuff like consts, types, funcs, methods order, struct initialziation newlines and other details that do matter, but they should be decided one and then applied everywhere like that.
Granted, this is a linter, not a formatter, but my larger point is I am glad that Python ecosystem evolved like it did recently.
Go can get there, but like I said, I think everyone is building some partial tools that solve some problems, but there is not that one player building that one great tool.
Not sure what you're talking about.
That's not the fault of golangci-lint, it's just the concept of bringing together a bunch of different linters and keeping it fast is impossible. And the configuration is a bit wild too, because every linter obviously has their own decisions on how it wants to be configured.
Ruff can lint in seconds or even sub second.
Compare that to Python or TypeScript which are Wild West languages without opinionated first-party tooling, and it’s clear why Ruff/Biome feel great.
You just wouldn’t get that same high with Go.
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
(Honestly go's distributing itself has covered a lot of it)
https://github.com/gempir/strider
It's definitely possible, if Google would put like one or two smart minds on the problem full time they could easily solve this problem and make the ecosystem so much stronger. But I'm guessing they already have something like this in-house and no interest in open sourcing it.
Not unlike that experience, I also saw coding agents spend lots of tokens trying to fix a benign issue, as well as doing the opposite - like disabling the tests !!! when they don't pass. :facepalm:
I grew to trust AI results in terms of overall correctness, but I still have hard time trusting their *judgement* on the *code quality*.
Don't get me wrong, the new level of details coming from Ruff is much appreciated and a good thing :)
Generally gets you 90% there.
Good thing we have LLM:s that can do the tedious work of checking each case and applying local annotations or updating the config globally! If I was stuck doing this manually, I would have just gotten rid of ruff and went back to black+pylint.
I sorta kinda get why `ty` is pre v1.0.0 -- it's a typechecker that doesn't check a huge number of types. But what are we waiting for with `ruff`? Surely it's eaten whatever the old options were (black? maybe a few takes on py+lint?) by now many times over, and is even more dominant than `uv`.
I run this program hundreds of times a day so I'm generally excited for new features, but I guess the OAI acquisition has made me ornery when it comes to these folks. Apologies to kindly nerds who made this release happen, and congrats <3
It is fully according to their versioning policy:
https://docs.astral.sh/ruff/versioning/
But also compliant with semver:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
https://semver.org/
(Maybe I misinterpreted your remark, but semver does not get hurt.)