Every new single piece of software calls itself “extremely fast”, “blazingly fast”, it gets tiring.
Compare it to some of the other options in that space and you'll see why that was a selling point.
Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
161–170 of 247 posts
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#162Earlier quoted context omitted.
I do not have any opinion on formatting. My argument is that nobody should.
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 instead of one, replacing quotes) and the rest make my code verifiably worse (folding a list in one line).
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#163Earlier quoted context omitted.
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.
[flagged]
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#164Earlier quoted context omitted.
Well, it’s nice you bring up strawmen after you called me a hobgoblin (a delicious word btw). I hope this _divine_ irony is not lost on someone like yourself. > I learned that my style is somehow "bad." That’s what you are missing: your style is not bad at all. It’s just your style. Use it for yourself! Teams work on shared ground. Automatic formatting is just part of that shared ground.
I’ve written it up-thread: you want me (and possibly, everybody) to be a cog wheel. But I want to be an artist.
It’s fine to be Howard Roark on a commission or pet project by yourself or a small team, but not when working on a subdivision with many hands touching it
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#165Earlier 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…
There's a ton of variation in golang code, as gofmt is not opinionated enough. As evidenced by the existence of golines[0] or gofumpt[1].
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#166Earlier quoted context omitted.
Well, it’s nice you bring up strawmen after you called me a hobgoblin (a delicious word btw). I hope this _divine_ irony is not lost on someone like yourself. > I learned that my style is somehow "bad." That’s what you are missing: your style is not bad at all. It’s just your style. Use it for yourself! Teams work on shared ground. Automatic formatting is just part of that shared ground.
I’ve written it up-thread: you want me (and possibly, everybody) to be a cog wheel. But I want to be an artist.
I don’t want you to be anything but a team player. Let’s work together and get it done.
Be an artist on your time, not mine.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#167Earlier 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.
Then go be an artist and leave the rest of us to tend our well oiled machines.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#168Earlier quoted context omitted.
The other commenters seem to be commenting on style consistency but ignoring your example. Your original format is far easier to read and understand plus the meaning of the comment is lost. IMO you're completely right about this example. Single line dict definitions shouldn't exist. Dicts are far easier to understand and manage when each key/value pair is on its own line, regardless of length.
Thank you, but I'm afraid I disagree. Single line dict definitions are fine when that's my intent , multilines are also fine when that is, and I trust myself to know when to use one or the other. My problem is with arbitrary rules like "only x -line dict definitions are allowed," for any value of x .
Yeah, you've ruffled the feathers of people who've been conditioned to strive for uniformity through conformity. Alas you're tilting at windmills in this age of automatic code generation where people look at the general shape of the code and check its intent by running it.
Nobody even addressed the other issue you expressed about uncomprehensible code being fine for linters as long as it conforms to the style guide or low-hanging fruit of "don't use this deprecated method". Who knows, maybe soon enough someone will make a dev tool which runs per file, acknowledges your clever little piece of code and then yells at you that nowadays programming is a team sport called software engineering.
Personally it saddens me that I must agree with the other commenters even if I see where you're coming from. The mass produced, assembly-line with snazzy pipelines took over from the workshop in a wood shed style approach and code linters among other dev tools slot in much better in the former type of workflows than the latter. On one hand I want to be trusted to format my own code according to my intentions but it seems the majority has decided that this is a waste of time, needless bikeshedding and so on. I've begrudgingly gave in for the sake of collaboration which is more important to me in the grand scheme of things.
I guess the upside remains we're still free to do as we please on our own projects. Now to find similar thinking people huddling around Sublime Text shunning linters is not gonna be a cakewalk these days.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#169Earlier quoted context omitted.
I've never had discussions about code formatting in PRs, this seems like a made up problem or something that predates my career.
> something that predates my career That's because everybody uses linters nowadays, which was the original point.
I'm not convinced.
Re: Ruff v0.16.0 – Significant new updates – 413 default rules up from 59
#170Earlier quoted context omitted.
I've never had discussions about code formatting in PRs, this seems like a made up problem or something that predates my career.
> 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.
What is "back in the day" here? I've been in this field for like 16 years.