Mine is that the useState hook is an actual plague on the entire React ecosystem. Regardless of your opinions of React, if you wanna use something then use it right.
Mine is that the useState hook is an actual plague on the entire React ecosystem. Regardless of your opinions of React, if you wanna use something then use it right.
Linters are terrible.
Style/formatting linters, anyway, particularly when it comes to whitespace. The goal of formatting code with whitespace is to optimize for human readability. A linter based on a set of rules is not human and thus cannot judge human readability. There is really no formatting rule you can write that will not someday have exceptions on a large-enough codebase.
Contributors should be responsible for submitting readable code, and ensuring that is what reviews are for.
…which is why I love
#[rustfmt::skip]so much! You can do stuff like#[rustfmt::skip] const DIRECTIONS: [[i8; 2]; 4] = [ [0, 1], [-1, 0], [1, 0], [0, -1], ]while still enjoying the convenience of auto formatting elsewhere.
Although linters which act on the behavior of code are unequivocally a good thing, e.g. “hey, this comparison will always return false you probably made a mistake here”.
Any formatter annotation just clutters the code though. Except maybe if it is file-wide.
I prefer that my editor formats it in a sensible way as I code. If there’s something I wanna do with a different formatting, I just do so. But the rest is formatted as I write it, instead of afterwards.
I’ll go a step further: formatting for human-readability is the job of the reader, not the writer. Hardcoded line breaks, spacing, etc. are never going to be a good solution because the idea is wrong from the start. This is a display issue, not a logic issue. It needs to be solved at the display end.
Use a syntax-aware editor that formats code the way you like it. Save it any goddamn way that is syntactically valid. Anyone else who opens it will see it any way the like in their own syntax-aware editor.
“But my editor doesn’t do logical formatting!” Yes, because the entire world has been insane for several decades, and shitty editors are normalized. If the world had realized this 30 years ago, there wouldn’t be a code editor in existence today that didn’t do this properly. Demand better and better will be normalized.
So every MR restyles the code to fit your style? How are you going to review the code?
Every problem in computer science can be solved by adding another layer of indirection.
Whatever is displaying the MR formats it. The server saves a normalized copy.
Like crlf/lf. But for all formatting.
Sure. Toooootally the same thing. Now the server will have to save a copy of your formatting preferences, checkout the project at point t-1, checkout the project at t, format it, create a diff, and present that to you. Now when you leave a comment on line x, it might be line y for another person.
Or make it worse, someone introduces malicious code with UTF-8, or switches around parameters, or adds pragma comments that fundamentally change your code, but your formatter happily fixes that for you in the preview so you are oblivious.
Or you’re hosting this server and someone makes a change that completely reformats the entire codebase, but you see absolutely nothing of it because the preview diff only shows “relevant” changes.
All fine by you👌
Right. You can still put that through a linter; the linter just wouldn’t be concerned with human-readability.
In any case, my editor would not hardcode my display preferences, so if I open and save a document, nothing changes except what I actually changed.
Disagree. Linters catch common logic errors, formatters remove nearly all discussions about formatting style. I remember MRs being held up for days at work because of formatting discussions, being resolved by a “style guide” that couldn’t be memorised, and being followed by new discussions about formatting that held MRs.
The that epitomises this is the nixpkgs repo. There are thousands of PRs stuck in nitpick hell because some particular reviewer wants commas here and another wants them there.
Also, if they can detect mistakes, they should be able to FIX them instead of adding extra busywork on my table.