Skip to content

Loading…

Strongly disagree with single quote rule #96

Closed
marcandre opened this Issue · 26 comments

9 participants

@marcandre

You state:

"Prefer single-quoted strings when you don't need string interpolation or special symbols such as \t, \n, ', etc."

I disagree with that.

1) This is not a convention widely followed. For example I'd say that you will find more double quoted simple strings in Rails than single quoted ones (if you exclude requires which are typically single quoted).

2) It's a rule I personally dislike because I usually do not know if a string will ever require a special character or interpolation (again except for requires). Example:

raise ArgumentError, 'Expected a string'

could later become:

raise ArgumentError, "Expected a string, got #{some_arg}"

I dislike having to change single quotes to double quotes.

3) I don't think there is much to gain with such a rule. If there was to be a rule, then I'd say prefer single-quoted strings for strings that should not have special characters nor interpolation (like files to require), but for everything else, I think it should be a personal choice as many policies, e.g. double quote only when needed, or on the contrary single quote only when needed (my preference), both make sense.

@paulmillr

I'm :-1: on this:

  1. It's not as widely used as other rules but, well, the point of the guide is to promote things like this one.
  2. It's not a pathological case. If we've followed the "could later become" logic, we haven't used ternaries which could later become ifs, unlesses that could later become ifs and much more.
  3. Consistency is consistency in everything. I find the rule very helpful and i've strictly followed it in my projects.
@marcandre

Just to clarify a bit:

  1. This rule goes contradicts most code, including Rails'. I have no problem with people having their own rules, but this is officially a "community-driven and community-sanctioned set of practices". The community in general, Rails in particular, tend to contradict this rule. Just because of that point, I think this rule should be removed altogether.

  2. Consistency is good, in particular because it makes reading, understanding and modifying everyone else's code much easier. I don't think that having ' or " changes much to the readability and understandability of code.

@bbatsov
Owner

Rails' style is not Godsend... The rule will not removed as it makes reading the code a lot easier and consistency is generally a good thing. I have seen it applied in enough projects to know that it has enough of a footing in the Ruby community. This guide is not law, merely a set of guidelines - the choice to follow them or not is your own.

@bbatsov bbatsov closed this
@jhubert

For what it's worth, I also think this rule is ridiculous and contradicts most ruby programmer style (not just rails). I also don't believe it makes code any easier to read. I think you're exaggerating in order to justify a personal opinion. As much as I appreciate your efforts with the style guide, I believe you to be misleading ruby programmers with this rule and causing extra confusion and effort where it's not needed.

On a personal usage note, I find it annoying to have to copy the avoidance of this rule into every .rubocop.yml file and would far prefer to have sane defaults.

That being said, it's your code and I don't argue your ability to do with it what you choose.

@jdickey

@jhubert, I don't know about "easier to read" one way or the other; that's not why I follow (and support) the rule. I've been bitten by careless overuse of string interpolation before. Therefore, I'm coming at this from the exact opposite view of @marcandre when he opened this issue: I want something that makes me stop and think and ask "is this really a better (not just more immediately convenient) way to build this string than catenation or format or the two or three alternatives that pop into anybody's mind?"

It helps make me a more deliberate developer, which makes me a better developer, and that's why I support the rule.

@marcandre

For the record, I've changed my position. I now follow that rule (of single quoting unless needed) and love it. I like it visually and it's slightly more explicit, since there's no need to parse the string to see if it contains any expression.

@marcandre

@JikkuJose Thinking it might be about performance is plain wrong for at least two reasons. Please read this info about the performance aspect

@JikkuJose

@marcandre I didn't really get it. Quite a newbie to Ruby; So let me clarify: Is this to maintain consistent style? If so, why not use double quotes everywhere and find consistency like that?

In short does this just boil down to personal taste? and being consistent with rather large part of the community?

@onebree

@JikkuJose As mentioned, take the phrase Hello, world!. The string processes much faster with single quotes, than with double quotes. When you write a Ruby program with speed in mind, remember this. Otherwise, it is mostly personal taste. I use mainly double quotes, but will decide if that (noticeably) affects my test speeds. (I doubt it, with integration testing.)

And yes, consistency is the thing to take away from the guide. While it is a community guide, I have seen individuals/companies fork this project and tailor it to their needs.

@marcandre

The string processes much faster with single quotes, than with double quotes

?? what ??

@onebree

@marcandre I think faster than I type. I edited my comment

@marcandre

My comment stays the same

@JikkuJose

@onebree it seems there isn't any significant performance advantages for this choice!

@onebree

I do not have them on hand, but I have seen benchmarks showing that single-quotes process faster than double quotes. It may not be a large difference, but one nonetheless

@marcandre

@onebree Sorry to repeat myself, but please read this, and don't repeat stuff you don't understand and without references, as it will often be wrong (like in this case).

@jdickey

Over three years later and we still can't let this go. Some excessively masochistic PhD student will successfully defend a dissertation mocking the hell out of benchmarking fetishes, with this discussion (and @marcandre's SO answer) as highlighted sources.

@onebree

Just to clarify, I am not obsessed with benchmarks, but they do serve their purpose at times. I mainly use double-quotes, while a coworker uses mainly single-quotes. I think, if possible, we should burn this issue, since the guide includes both options.

Can @bbatsov lock it possibly?

@JikkuJose

Must have become sort of habit an d personal preference for many to just burn the issue. Personally, I don't see why someone should consider single quotes.

Anyways, thanks for your time.

@maicher

@JikkuJose By saying:

Personally, I don't see why someone should consider single quotes.

you showed a lack of understanding to:

I like it visually and it's slightly more explicit, since there's no need to parse the string to see if it contains any expression.

@JikkuJose

@maicher oh was it so? Then I am sorry to hurt feelings, I just meant the argument seemed just as an arbitrary choice. And I feel seeking consistency in using double quotes everywhere feels like a better choice.

@bbatsov
Owner

If I hear one more time the argument about performance... This was never about performance, it's a semantic rule and its benefit is obviously that more information is conveyed by the choice of the literal. There's really no right or wrong choice, there's no better choice, etc. I wish people would realize this someday, instead of wasting of ton of time bikeshedding and arguing over trivial details.

@onebree

@bbatsov can we close this, or lock the commenting?

@marcandre

@onebree It has been closed for over 3 years. Anyone can click on 'unsubscribe' to not get notifications.

@JikkuJose

Sorry to have brought it up. Thanks for your time anyways.

@roberts1000

@bbatsov There's really no right or wrong choice, there's no better choice, etc.

This is exactly why it should not be part of the style guide. There's no community accepted preference, no performance benefit one way or the other, and no clear readability benefit/preference. The time it takes to enforce this rule in a code base and pay software engineers to deal with is a complete waste. I disable the check in our .rubyocop.yml on every project and let my developers do whatever they want with their strings.

@pkarman pkarman referenced this issue in 18F/C2
Merged

Rubocop: enforce single quotes #705

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.