9 ms·
The amount of fascination that people have with these "grammar nazi" bots -- some of them implementing completely arbitrary "rules" and some of them disagreeing
by maratc 3mo ago
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.
- jbvlkt 3mo agoThose 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.
- maratc 3mo agoWe 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.
- jbvlkt 3mo agoPeople 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.
- maratc 3mo agoSo to the practical question: what we're gonna do today in CICD and/or precommit? "Default configuration is always the way" but which one: `ruff<0.16.0` or `ruff=0.16.0`?
- jbvlkt 3mo agoI would stick to older ruff until team has resources to fix issues and move to newer version. The same think you do with other dependencies.
- maratc 3mo agoI find it hard to look at ruff as at "other dependencies." First, my other dependencies usually deliver something of value to the customer (and so I deliver my other dependencies to the end-user installation.) Second, when I need to change code to accommodate other dependencies, it is usually limited to a couple of files, sometimes to a couple of modules; this change will touch much, much more than that. Third, my other dependencies at least play nice by implementing semver and bumping a major release on a breaking change. Nothing of that applies to this change. > fix issues Which weren't "issues" at all just this morning.
- jbvlkt 3mo agoI also do not like if project stays on 0 version to break compatibility with every minor version. This is the problem with many rust tools and libraries. I think it is unfair to do that years after first release and with healthy community. But it is a tradeoff and not using ruff is in my opinion worse. To your other issues, just do not upgrade. There is no need to upgrade everything a few days after release. I always lock ruff to version I like and upgrade whenever it is convenient.
- maratc 3mo agoI find it kinda amusing that we seem to have an endless and useless discussion on "what version of ruff to use" now when you kinda implied that you have some sort of a solution to these endless, useless discussions -- in a form of "just use ruff." > upgrade whenever it is convenient In my codebase, and with my environment, the best answer is never. We'll have to pick a second-best answer though.
- Hendrikto 3mo ago> 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. That is why gofmt is so great. As the saying goes: gofmt’s style is nobody’s favorite, yet gofmt is everybody’s favorite.
- LaGrange 3mo agoGods 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!
- jbvlkt 3mo agoYou can still talk to them about more important problems than placement of collons and closing bracket.
- LaGrange 3mo agoActually the aesthetic preferences of people I regularly work with are important to me.
- jbvlkt 3mo agoI do not have strong aesthetic preference for code (I always disable "minimap" in editors which shows it because I think about code as symbols shown in "outline"). I would probably not notice reasonable code formatting change if you would do it during my holiday. My requirements for formatting are purely technical (ie. do not make unnecessary diffs on code change). But I have worked with a few programmers who think about code visually. They actually remember code structure and formatting more than text and use "minimap" instead of "outline". They also strongly oppose any automatic formatting and linters. It is fascinating how different some people are despite doing the same work.
- brookst 3mo agoHow 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.
- LaGrange 3mo ago
- toxik 3mo agoI have never discussed code formatting and drive-by changes more than in projects with auto formatters.
- jghn 3mo agoWhy though? I've yet to come across an auto formatter that formats things the way I personally like. But that's fine. I do whatever the hell I want until I'm ready to open a PR, then bang it through the auto formatter. And you know what? I can also go the other direction and run a home-brew auto formatter to reshape things the way I personally want on my local machine.
- toxik 3mo agoI'm not sure why, but apparently my experience is unwelcome enough to be downvoted. Drive by changes are really annoying, IMO, and as the GP shows, the formatting tool outcome differs. So there are many "valid" versions of the same program logic. You have therefore not do what these formatters pretend to do, namely take this variable out of the equation. Rather, the wrong auto format can look much worse than the original. I'm not sure why people felt formatters were necessary. but now they're part of the zeitgeist and there is no going back.
- Majestic121 3mo agoThe 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.
- maratc 3mo agoIn 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.
- dewey 3mo agoWhich 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.
- phoghed 3mo agoWaiting patiently for the other person to produce a post hoc rationalization about why everybody’s code looking different is in fact a good thing
- insanitybit 3mo agoCan you not read code if it uses single vs double quotes?
- wodenokoto 3mo agoIt’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)
- maratc 3mo agoSorry, 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.
- slig 3mo agoMust be nice to write code with the hopes that only intelligent people will read it.
- CuriouslyC 3mo agoThe 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.
- mylifeandtimes 3mo agoyes, and isn't it funny that foo=[baz, bar,] returns a nice list of two items, but if you edit this down and miss the comma, foo=bar, is not a scalar. returning a tuple. So the trailing comma thing is a thing.
- 9dev 3mo agoYou will find that pretty much every rule we have in any possible context will have some exceptions that are justified under some conditions. 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.
- elteto 3mo agoThe 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.
- maratc 3mo ago"A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines." -- Ralph Waldo Emerson
- elteto 3mo agoTIL I am divine! 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.
- maratc 3mo agoYou can build yourself any strawman you want :) In my first ten years of writing Python, I never argued about code style with anyone. It's only after they brought the bots in that I learned that my style is somehow "bad."
- elteto 3mo agoWell, 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.
- maratc 3mo ago
- cyberrock 3mo agoIt'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.
- tclancy 3mo agoYou 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.”
- maratc 3mo agoYou want to be a cog wheel, in a company of cog wheels. There's nothing wrong with that. But I want to be an artist, and preferably in a company of artists, having been in a company of cog wheels too many times. Not only it's more fun that way, but also tends to lead to better outcomes.
- kstrauser 3mo agoThat's an uncharitable take and I urge you to reconsider. I also take great joy and pride in the art of writing beautiful code. I have no desire to be a cog in a machine. However, my ADHD brain is delighted to not have to make a million little distracting decisions in place of the code planning I should be doing. Formatters let me concentrate on writing the best data structures and APIs and algorithms instead of how many spaces to put before comment markers or while kind of quote mark is more aesthetically pleasing in this particular file. I, too, want to be an artist. For me, the flow of data through my work is the artistry, not the typography of the code.
- 3mo ago
- vorticalbox 3mo agothis is why i like golang these sorts of things just don't matter, go fmt move on with life.
- NeutralCrane 3mo agoI agree with you, but that is literally what ruff is meant to do, and what this person is arguing against.
- OoooooooO 3mo agoSame for rustfmt. I love gofmt, rustfmt, ruff.
- atoav 3mo agoYes sure, but the point of something like ruff is that you don't even think about formatting anymore. It is just done for you and it is done consistently.
- driverdan 3mo agoThe 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.
- maratc 3mo agoThank 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.
- aquariusDue 3mo agoYeah, 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.
- NeutralCrane 3mo agoThis 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.
- maratc 3mo ago> 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.
- MawKKe 3mo agoSounds 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.
- maratc 3mo agoThe 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.
- rsyring 3mo agoI've read through all the sub-comments you've left here. In short, you seem to have a grievance against linters that goes way past reasonable. You assert this example you give is "perfect" below. You also complain linters waste time and commits despite able evidence in the field they do the opposite. You seem willing to add drama, grievance, and personal bias to what could have been a rather straightforward technical discussion. The sum of which is: linters sometimes make changes to code that I don't like. I'd encourage you to reconsider what's really important when it comes to team development and try listening more to those around you. You seem overly focused on asserting your opinion instead of having a discussion. These types of exchanges are usually very unproductive and stressful in a team environment. They are evidence, IMO, of a dev having the wrong priorities. I'd encourage you to step back and really consider how you view craftsmanship in a team dynamic and whether or not you are fighting the right battles.
- colechristensen 3mo agoA person just as opinionated as the tool. People who have very strong opinions about formatting in any direction are suspect.
- maratc 3mo agoI do not have any opinion on formatting. My argument is that nobody should.
- colechristensen 3mo agoyour 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
- maratc 3mo agoYeah, 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).
- somat 3mo agoOh man, list comprehensions, that's me. I get inspired, caught up in the flow, write some eldritch horror of a LC. 30 seconds later "What in the name of saint Lovecraft does this even do?" (sighs) Rewrite as a loop. I mean, I guess they are fine in small doses, very small doses, But boy do they read poorly compared to the rest of Python. I also need something to save me from my regexps, the verbose flag helps a lot. but what would be really nice is some sort of python subset that could compile to the state machine. I would also like composable expressions, that is, composable at the graph level not the string composition we are forced to use. And a pony, I would also like a pony. As you can tell I am not a fan of APL, not because of what it can do but because of the super compressed syntax it adopts. see also: perl
- dirtbag__dad 3mo ago> 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. 100%. Almost all of my time burned navigating code is not hung up on stylistic conventions but on nasty services with inconsistent abstractions and patterns. BUT, conventions and consistency make code easier to read and write, period. If you’re debating over single or double quotes that’s almost a fireable offense IMO. Additionally, when you have a culture that delegates to tools as much as possible, the focus sharpens in a healthy way.
- tclancy 3mo ago> it's the 10-line list comprehensions I feel for you both working with straw men day to day. I’ve worked mainly in Python for two decades and have neither seen such a thing nor considered, even to be a bastard, doing such a thing.
- gchamonlive 3mo agoThe "bad" code is actually bad imho. The comment explains intent inside the object rather than on the spec, which makes it easy to miss and harder to discover later. This seems like a case where the tooling is compensating for unclear conventions. Collaboration tools are useful, but it may be more effective to strengthen the code specifications and documentation practices first, so intent lives in a predictable place instead of being scattered through implementation details.
- ckolkey 3mo agoPut a comma after "'z': 2" and it will work how you expect, fyi
- tipsytoad 3mo agoStylistically ugly code that is globally consistent (ideally across the entire ecosystem) >> locally beautiful code that is inconsistent with the rest of the codebase / up to authors taste. No one likes black formatting, but it’s at least consistent. “Your car can be any color you like as long as it’s black” With regards to your example, adding a comma to the final element should preserve multi-line. You just don’t know the formatting rules yet apparently
- brewmarche 3mo agoFWIW, ruff sees your line comment and keeps each item on its line. It only adds a trailing comma and additional space. It also does not collapse lines when there’s a trailing comma. Your output seems to be from black. IMO it’s insane to collapse lines when there are line comments. $ uvx ruff format --diff formatting.py --- formatting.py +++ formatting.py @@ -1,8 +1,4 @@ -no_comma = { - "x": 3, - "y": 42, - "z": 2 -} +no_comma = {"x": 3, "y": 42, "z": 2} with_comma = { "x": 3, @@ -12,6 +8,6 @@ comment = { "x": 3, - "y": 42, # Answer to the Ultimate Question! - "z": 2 + "y": 42, # Answer to the Ultimate Question! + "z": 2, } 1 file would be reformatted (I intentionally switched to double quotes since that really is a stylistic choice in Python, you can escape in both, and if you use double quotes inside of single quotes ruff leaves it as-is)
- zelphirkalt 3mo ago(am not the GP) I personally like double quotes, because in so many other languages they are for strings, while single quotes are often for other things. But somehow many people have a single quotes obsession in Python. I am guessing, that it is because of ease of typing them on a US keyboard layout.
- maratc 3mo ago> many people have a single quotes obsession Not my problem. My problem is that I want to use them both, as I've been able to for many years. I'll always use double to surround "can't" and single to surround '8.5" x 14"'. I'll use a context-appropriate pair when adding to existing code. But for all the other cases, I don't want to expend any energy on this. It's a complete non-issue. > ease of typing them on a US keyboard layout On both the US and European keyboards single-quotes are easier: no need to press Shift.
- MayeulC 3mo agoRegional keyboards are a mess for coding. I'm much happier with a qmk-enabled keyboard where I remap keys in hardware. For instance, on a French keyboard: - easy: " ' , : * ! - _ = ( ) - harder (shift): numbers . µ ? / ℅ + - hardest (Alt Gr): []{}€~|`^\@# This is not exhaustive, but some of the most common symbols are quite hard to type: not surprising as most language designers use US keyboards. Still, I think everyone would benefit from a "symbols" layer on their keyboards.
- amingilani 3mo agoRuff/black support and enforce this. Just do ‘'z': 2,’ If you add an extra dangling comma at the end of the last item, ruff/black will auto-format to the line-by-line style you like.
- zelphirkalt 3mo agoYep. So far I have found every auto-formatter tool to be hopelessly naive in its workings. No, sorry, I do not want my logger call to stretch over 5 lines of screen real estate, just because the silly tool doesn't allow to distinguish between logger calls and other stuff, and a log message can be > 80 characters. They often make code less readable than before. I am still traumatized from adding trailing comma to every multi-line call, due to black being "opinionated" and always moving things back to one line, making them less readable, if they are not longer than some limit. It's silly.