Comment by robotmay | Hacker News Reader

Comment by robotmay | Hacker News Reader

Parent Full thread

We use rubocop heavily at GitLab. I'm generally happy with it, and we have a largely sane set of linters. I think when your codebase gets to a certain size and you have a lot of engineers working on it, having some sane defaults is very beneficial and helps standardise the codebase a bit.

Where I think rubocop really shines is in picking up _problem_ code, like potential bugs, performance issues, or errors, in advance. We also use it heavily when deprecating older modules/classes, like replacing JSON calls with our own wrapper.

It does, however, sometimes suggest something totally bonkers: https://gitlab.com/gitlab-org/gitlab/-/issues/271570, but it's fairly trivial to skip it. After all, humans should be allowed to say that the linter is wrong and either ignore it or suggest an improvement, and that's a process issue rather than a rubocop issue :)

Not everyone is going to agree with every cop you enable, but the goal is standardisation rather than appeasing everybody. If something is particularly contentious then I would suggest removing/disabling that cop.

Every few years at GitLab we do seem to get a singlequotes vs doublequotes cop argument crop up, which is why we (thankfully) still don't have any requirement around those. Team doublequotes represent!

Edit: Oh and unrelated to the content of the article, but I really like the design and colour palette of the blog.

> Every few years at GitLab we do seem to get a singlequotes vs doublequotes cop argument crop up, which is why we (thankfully) still don't have any requirement around those

So you randomly have single and double quotes throughout the codebase?

I don't care which one a project uses, but it seems wise to pick one. Uniform syntax is very helpful for code readability.

Double quotes allow you to do string interpolation, which is not possible with single quotes. So I assume one faction argues that everything should be double quoted because it's does not matter if there's interpolation or not, while the other group would rather only use double quotes when necessary, otherwise use single quotes.

I'm personally part of the second group simply because my linter forced it, but at the end of the day, it's such a low impact we don't really care.

> would rather only use double quotes when necessary, otherwise use single quotes

So in that case, they're not used randomly according to the individual user's preference. There's a consistent rule. It's helpful for readability, too. And not sure about Rubocop in Ruby, but many linters in other languages can pick up on these different applications.

Generally in ruby/rails, the people in favor of double quotes would use double quotes all the time.

Rubocop would have you use singles for non interpolated and double for interpolated.

I get that there is a potential to catch some kind of error where you use double quotes on a string that will interpolated something which it wouldn't if it were in single quotes. In 12 years, I've never had that happen. I have, however, had it happen dozens of times where I changed something from interpolated to not and then I have to bounce over to change the quotes. This happens a lot and is annoying.

It's also an eyesore when you have an array of messages, each neatly aligned, but some are interpolated and some aren't, so the quotes change.

In Ruby, knowing that a string has interpolation is easy enough by seeing the #{} in the middle of it. It's hard to miss, really.

The single/double quote cop which is turned on by default is also counter to the existing style of every-string-is-double when it came along.

interpolation isn't the only difference between single- and double-quoted strings. If you need control, etc., characters via backslash escapes, you must use double (or semantic equivalents like %/%Q). If you need non-eyesore strings with literal backslashes, you need single (or semantic equivalents like %q.)

  irb(main):001:0> puts '1\t2',"1\t2"
  1\t2
  1       2

> In Ruby, knowing that a string has interpolation is easy enough by seeing the #{} in the middle of it.

{} are not required for instance variables.

> the people in favor of double quotes would use double quotes all the time.

Fair enough. I'm not much into Ruby but if I were, that's what I would encourage. But I'd be ok with whatever house style, as long as it's consistent.

Rubocop does pick it up by default.

> Uniform syntax is very helpful for code readability.

I don't understand this argument. Are people really having trouble reading code because it has two different quote characters? This goes against my understanding of "readability"? What is it that is really meant by this?

I don't think anyone is trying to make the case that a single stylistic preference impacts readability, but in aggregate many diverging preferences definitely can.

Add in programming styles and a flexible language like Ruby can look like entirely different languages from one dev to the next (Ruby is a very traditional OOP capable language, or a weird but capable lisp, mix the two and readability suffers in new and exciting ways).

Agreed, anything trivial enough for a linter to fix probably didn't matter in the first place.

Ah ha, yes I would say it would make sense to pick one, but only if that one is doublequotes ;)

Personally I have a few reasons why singlequotes are inferior:

- String interpolation requires doublequotes

- Using an apostrophe requires you to escape it or use doublequotes

- They're harder to type on a Japanese-layout keyboard, which I use (it's shift+7, lol), which is otherwise really efficient for Ruby

But there are arguments against doublequotes too:

- I guess they're maybe harder to type on an ANSI keyboard?

- They parse ASCII escape codes, and singlequotes don't

But in my experience I need to use interpolation and apostrophes more than I care about not parsing \r so I use doublequotes everywhere in my own codebase.

So I would just rather not force either, as people seem to feel strongly both ways and the added frustration is probably worse for productivity than having it look a bit neater :)

Honestly I think the "community" chose wrongly in trying to standardise on singlequotes-unless-you-need-interpolation, when it should probably be doublequotes-unless-you-have-a-good-reason, but it's pretty hard to change that now.

> Every few years at GitLab we do seem to get a singlequotes vs doublequotes cop argument crop up

...when obviously the correct answer is to consistently use %.

/s

I was wondering about proposing that as a compromise. Or heredocs :D

Reply on news.ycombinator.com