Back

I mention quoting styles specifically because when I asked folks what Rubocop rules they thought were particularly helpful... Mostly, the answer seems to be no particular rules, they just want things to be uniform.

The exception is rules about quoting strings, which got mentioned by far the most of any specific rules, but sometimes in specifically-trolling ways.

So apparently it's not that any specific rules are good, but if we could avoid variety in string quoting... Something good happens?

@codefolio a shocking number of people seem to just think personal style is a crime of some kind... see also, rust having "style warnings" /built into the compiler./ And turned on by default. (One of the big reasons we don't like Rust.)

@frostwolf I don't worry too much about personal style. But I *really* like being able to change stuff in different circumstances -- along the same lines as Rakefiles looking like Makefiles, Rails looking different from long-line ETL code full of SQL queries and so on.

In theory I suppose I could compose a slightly different rigid straightjacket of rules for each occasion. But just *not* doing that seems solidly better to me.

@searls Fair enough. I just don't have trouble reading a variety of codebases.

Which is good, because it's been many years since I've had a job that didn't require that weekly-or-more.

So then presumably other people *are* significantly bothered by inconsistency in whitespace and quoting.

But sure, I agree that getting a group to agree on a style guide and then use it consistency is very hard, and most style guides are awful.

@codefolio I don't "have trouble" reading a variety of code styles. Nor do I have trouble using either of metric or SAE socket wrenches. But if you mix them together arbitrarily, it's going to take me longer to do the job.

I see meaningless inconsistencies in code the same way.

@searls @codefolio regarding string quotes: I don’t have a problem reading them if they are different. But consistency is relaxing.
Minor inconsequential differences get distracting over time and train you to ignore differences. That’s bad when differences mean something.

@searls @codefolio Choosing to standardize on a string quotation that only works without interpolation and must be changed if you decide to interpolate is absolutely ridiculous and I can’t believe people blindly accept it from rubocop.
I will die on this hill.
Sorry. I know that’s a digression from the conversation but I’m just astonished that single quoted strings are what rubocop decided was good.
If I decide to interpolate then I ALSO have to change the string delimiter!?

@saturnflyer @searls @codefolio I'm 100% convinced this is caused by utterly outdated notions that single-quoted strings are faster/more efficient when they have not been for at least over a decade.

Perfect example of this: https://stackoverflow.com/questions/1836467/is-there-a-performance-gain-in-using-single-quotes-vs-double-quotes-in-ruby

But worse than what you describe is my early days watching "senior" Ruby developers use backslashes in single-quoted strings to do interpolations without having to switch to double-quoted strings.

I just... could not.

@olivierlacan @saturnflyer @searls They're not faster these days, no. They're *really* not faster in Rails, where you have Bootsnap and parse-time isn't a thing at all, full stop.

I can understand the argument that you'd want to see whether interpolation occurs, as a human thing.

But yeah, optimising Ruby for fast string parsing would be really, really silly even if it worked, and it doesn't.

@codefolio @olivierlacan @saturnflyer @searls I'm not sure they've *ever* been faster in Ruby. They were only briefly faster in PHP many moons ago and that was because PHP didn't even construct an AST

@sgrif @olivierlacan @saturnflyer @searls Fair. By the time I knew of anybody testing they were clearly not faster, but no clue about, say, 10+ years ago.

But yeah, wouldn't surprise me if they weren't faster then either.

@jswright61 @saturnflyer @searls A number of the Rubocop standards are very explicitly *not* designed to conform to Git (or other diff-based source control.) Commas on last lines of arrays, etc, too. They're very explicit about being against altering their tool to accommodate other "tool limitations" (that is, that Git is diff-based.)

@jswright61 @saturnflyer @searls Re: inconsequential differences and differences being meaningful...

If you're going to be sure at a glance that string differences are meaningful, and have immediate gut-level confidence in that, you need to train yourself *not* to read the vast world of outside-your-company code that does *not* conform to your expectations, such as your gem dependencies.

Maybe that's a reasonable constraint for other folks? It's kind of hard for me to imagine.

@codefolio @jswright61 @saturnflyer right, which again is the whole point of Standard. The more projects adopt it, the less friction experienced by everyone hopping across projects. There's a reason why people like @tenderlove and @fables_tales "got it" right away -- we work in literally hundreds of repos

@searls @codefolio
I am a simple homosexual, I like saving the file and having the code snap in to place

@trevorturk I can see how various setups (carefully-chosen rules, fewer rules) can make it less onerous.

I just don't get what the benefit is in return for the work.

@codefolio Yeah, I think there's some benefit to a mostly agreed upon code style, but imo a lot of the rules are just weirdo bike shedding, like double quotes vs single quotes gimme a break!

@grillermo Yeah. I've worked at places with a "no bringing up whitespace, capitalisation or style issues in code reviews" rule. It worked great for me.

Enforced arbitrary rules are sort of like that, but with build failures for whitespace issues.

I liked the way Go made it fully auto-enforceable. I haven't found Ruby tools manage that nearly as consistently.

Which makes sense. Ruby tries to be eloquent and expressive, and those aren't things you can do or preserve with an autoformatter.

@grillermo I see Justin's point, in the sense that if you're going to have one of those you want it to have a limited set of rules, and to use the same set repeatedly.

It just seems like a lot of annoyance to save you from bad quoting or whitespace.

@codefolio “try your best to follow the existing style, use your best judgment” — that’s my motto.

@codefolio and if you *are* going to enforce style, it had better happen automatically on save!

@justinweiss @codefolio This is my view on it, too. I want the robots to take care of tiny details I overlooked, but I only want them to get in the way to stop me from doing a big bad that’s subtle and easily missed in human code review.

@jamie @justinweiss Yeah. You could imagine a tool for that, but Rubocop isn't it.

@fpsvogel There's probably a better term for it. I mean the "this is a real mistake you made” cops, or "technically you can do this but it's never actually correct”

@codefolio I work in a lot of different codebases, so I'm comfortable navigating unfamiliar and inconsistent code, including source diving dependencies. But I am able to work much faster in code that has thorough and consistently applied standards.