Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Purposeful choice between double-quotes and single-quotes #849

Closed
mhelvens opened this issue Apr 9, 2017 · 3 comments

Comments

@mhelvens
Copy link

commented Apr 9, 2017

Hi all,

I found that string literals in code, in 99% of cases, fall under one of two categories:

  • Strings meant for the computer to read, e.g., code, keys, regexes, urls.
  • Strings meant for humans to read, e.g., instructions / error messages in English.

My team follows the convention that single quotes are used for the former and double quotes are used for the latter. For example:

obj['error-message'] = "The requested entity does not exist."

Of course, the nature of string literals is not always clear from context like that, and using the double-quote / single-quote convention always makes that nature clear to us at a glance.

From what I understand, standard mandates double quotes for all strings that do not include double quotes themselves, and general exceptions are not allowed. So consider this either a question or a feature request. Is there any way for us to have our cake and eat it too?

@nickmessing

This comment has been minimized.

Copy link

commented Apr 9, 2017

You can still use standard as eslint config and add your rules on top

@dcousens dcousens added the question label Apr 9, 2017

@feross

This comment has been minimized.

Copy link
Member

commented Apr 10, 2017

@mhelvens From what I understand, standard mandates double quotes for all strings that do not include double quotes themselves

Other way around. 😄 The readme says "Single quotes for strings – except to avoid escaping".

Is there any way for us to have our cake and eat it too?

Yep. But you'll have to use ESLint and install our shareable ESLint configuration: eslint-config-standard. That will make it easy for you to layer your own rule additions/deletions/changes on top of the base standard rules.

But beware! 😨 You might be inviting bike-shedding and style debates by leaving it open to customization. But every team team is different, so you have to decide for yourself.

@feross feross closed this Apr 10, 2017

@mhelvens

This comment has been minimized.

Copy link
Author

commented Apr 10, 2017

@nickmessing @feross: Thanks! I missed that solution in the readme.

But beware! 😨 You might be inviting bike-shedding and style debates by leaving it open to customization.

I understand that reasoning. But seeking refuge in the other extreme (having all those choices made for us) feels like an equally unhealthy option to me. (Though I'd be happy to reconsider. Are you aware of any actual studies?) In any case, thanks for offering this compromise!

@lock lock bot locked as resolved and limited conversation to collaborators May 10, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
4 participants
You can’t perform that action at this time.