Hacker News Reader

Comment by dwheeler | Hacker News Reader

I'm not excited. I think it's very important to have good defaults. But "you can't configure it" means you can't have changes that adjust to the situation.

Let's look at a mentioned example:

> Increase consistency around things that don’t matter. For example, Standard requires all string literals be double-quoted. Single-quotes don’t support interpolation but aren’t any more performant, so mixing single & double quoted strings adds a bit of cognitive overhead with zero discernible benefit.

But there are discernable benefits. Single-quotes are great for indicating "there is no interpolation here" and for strings that embed double-quotes.

Rubocop is great, though, and highly recommended if you do Ruby things.

View on HN

> Single-quotes are great for indicating "there is no interpolation here" and for strings that embed double-quotes.

I used to think that too. But it doesn’t really help that much, because interpolation is fairly obvious with syntax highlighting. I changed my mind and I prefer consistency, and have every string the same. Also, if you need to add or remove interpolation then you don’t have to change the type of quotes.

Rubocop can autocorrect strings to use the "correct" quotes based on context. The rule for "Standard" is silly and unnecessary. The argument about readability falls flat with me.

At the end of the day, let the tools enforce this nonsense, but I'm still a performance wonk at some level and it drives me crazy seeing interpolatable strings without interpolations.

There is zero performance difference between single quoted strings and double quoted strings with no interpolation.

Theoretically parsing "" should have very little overhead only on parsing, but parsing string is tiny work so it can't be problem. Anyway who cares such performance won't use Ruby.

That's interesting.

I was told about a ruby project years ago where they gained a measurable performance boost by converting all the strings without interpolation to single quotes.

That's a vague anecdote so should be taken with a pinch of salt. Even if it was once the case VM often improve to fix these edge cases.

So I was just wondering if there was anything more formal to prove this so that I can avoid this preconception I've been carrying around for years based on nothing more than someone's now dated Lightning Talk.

Here's a good summary by someone on StackOverflow, with links to Ruby source: https://stackoverflow.com/a/1836838/2850811

Thanks for the reply. It seems that any cost is small and at parse time rather than runtime.

That seems like a good enough reason to always use double " for consistency to me.

Yeah, I don't see this having the same sort of diligence around additions (or even the initial ruleset) that would be present in languages with inborn opinions like Go and Rust.

It really seems like a bunch of arbitrary linting rules that this company likes to use, and they are trying to push it on the masses as "Standard", which the uninformed won't understand the nuance of.

I think the name is really predatory.

Yeah, the name really annoys me as well.

I agree I was confused by the name, as I thought this was something formally related to Ruby, not some sort of Rubocop alternative.

It's not even a Rubocop alternative. It's an opinionated Rubocop wrapper.

I absolutely hate this kind of nitpicking, and am loathe to see it enforced, especially if the org has the bright idea to try to wire this up as a precommit hook.

Single quotes, double quotes, who cares? Oh no, you might have to change some extra characters. Such big cognitive overload, very hard...

All this 'standardization' is stripping the individuality and artistry from writing code. Sometimes I feel like the only person in the world who likes being able to look at code and know who wrote it by the style that they use.

In Ruby, especially, where expressiveness and being a little weird feature so prominently in our cultural heritage. If I wanted to be a conformist I'd write Javascript for a living!

im guessing, but i assume this is more for industry, where they usually neither want nor appreciate individuality and artistry

(this isnt a criticism or anything, just my observation)

In industry, the prevailing code standards are almost certainly wildly divergent from any sort of Ruby "best practice".

In particular, if the goal is to have clear (and therefore somewhat more likely to be robust) code, you're going to see things like the use of single quotes to indicate "this will never be interpolated" or the use of explicit return statements even when "unnecessary" - both of which run afoul of these sorts of highly-opinionated and unconfigurable style enforcers.

There's not much artistry in being individualistic about trivial things such as '' vs "".

As long as a project I'm working on is being consistent about them, I'm good.

A team can and maybe should agree on a style, and enforce it, for sanity. That can be done while still allowing all the fun parts of writing Ruby.

This project tries to go much farther.

> I absolutely hate this kind of nitpicking, and am loathe to see it enforced, especially if the org has the bright idea to try to wire this up as a precommit hook.

I find this so strange. I also loathe nitpicking about syntax which is precisely why I think this would be a great tool!

I work in JS now on a large team and one of my least favorite activities is trying to find consensus on which linting rules we should/shouldn’t adopt. It’s such a waste of time!

Setup Prettier and never talk about style again.

(Linting is slightly different -- just use some sane eslint defaults and call it a day)

Another vote for prettier for JS/TS. The primary projects I work on we made some slight tweaks to the default style (wider line width) and though some people were unhappy about adopting a formatter, there have been zero beefs with prettier's actual output among an opinionated group.

Prettier has been the cause of most arguments about style for JS code I've been involved in recently. For starters, it tends to blow up diffs because you get above/below arbitrary limits and trigger a more extensive reformatting than necessary, and it's infuriating.

I find the argument that it will stop discussion of style bizarre, because it only shuts down discussions about style if you already have the power to tell people what the accepted style for your organisation is. In that case you don't need a tool that refuses to let you pick and choose, you just need the confidence to tell people you're not going to change things.

In other words: It's not Prettier that stops you from having discussions about style again, it's whether or not you signal to people that you're not willing to discuss it. To me, in that respect, a tool like this is a passive aggressive way of signalling that you're unwilling to discuss the subject without being willing to just say that you're not.

> I find this so strange. I also loathe nitpicking about syntax which is precisely why I think this would be a great tool!

The antidote to nitpicking isn't to force something where nitpicking isn't possible/already resolved, it's staying open-minded and flexible enough to not let the nitpicked things bother you. "There are many roads to Rome" and all that.

Personally I like it, none of this stuff is worth my time to worry about configuring.

I categorically refuse to use tools like this that tries to force a single set of formatting rules, as I've yet to ever see one that hasn't been infuriating in all kinds of ways, because the "things that doesn't matter" to the people building these projects tends to be things that does matter to other peoples sense of what a well formatted program should look like.

As you say, a configurable tool with reasonable defaults to encourage people to only change the things they actually have strong feelings about, fine.

Go’s fmt seems to do a pretty good job in this area

I avoid Go as much as possible in part because I find its syntax horrible, so I can't really tell whether or not I'd be annoyed by go fmt's formatting if I had to use Go more regularly.

I do a lot of Go (years worth) and whilst I still dislike the standard formatting conventions chosen by `go fmt` I do like that I don't have to be concerned about them at all. For Goland, VSCode, or whatever, I just switch on format-on-save and format-on-paste and I'm good to go (so to speak).

The same with Node. I dislike the output of the (also named 'standard') eslint formatting rules I usually end up using, but by activating the auto-format as above the whole issue is redundant.

In other words, I dislike the format but as long as the code is readable I don't care - though as a writer the aesthetics of the formatted code disappoint me, so I can see both sides.

PS. As an aside the mention of prettier elsewhere makes me shudder. I, too, find that a threshold is reached whereby instead of small localised formatting 'fixes' it decides to change a fair amount more than expected which, as mentioned, makes for unnecessarily convoluted commits.

This kind of discussion is the exact reason I want someone to pick the default and make it unconfigurable.

If it's configurable then I'm going to end up wasting time talking about style rather than focusing on functionality. It's the exact reason I've set up my team's code with standard (and Prettier)

Reply on news.ycombinator.com