5

My current coding style is to use single-quoted strings as a default, and use backticked template literals whenever I need to concatenate a value into a string.

But I'm now wondering what's the point in having two kinds of string at all? Maybe it would be better to stick to template literals for everything, for simplicity. Even if you're not actually interpolating a dynamic value into the template literal, there's still the other advantage that with templates you don't have to bother escaping literal quote marks (which occur way more often than literal backticks).

So I'm considering configuring my linter to warn me when I use plain quoted strings (single or double). Aesthetics aside, is there any reason why this would cause problems?

callum
  • 10,377
  • 9
  • 30
  • 33
  • 1
    You seem to ignore that javascript evolved as a scripting language for the web - it had to interoperate with HTML. In particular - with how attribute quoting works. It still does, even if not in every environment it is used. – Oded Feb 08 '16 at 12:32
  • Not sure what you're getting at. I'm not discussing whether JavaScript should or should not have evolved the way it has, just asking whether there's any practical reason to continue allowing single- and double-quoted strings in my in-house coding standard for ES2015 code. – callum Feb 08 '16 at 13:02
  • 5
    The main thing that comes to mind is if you have a "non-backtick string", it's immediately obvious that no interpolation is going on so the string is exactly what it appears to be, and there's zero risk of accidentally adding interpolation if you need literal $s and {}s in your strings for some reason. – Ixrec Feb 08 '16 at 13:23
  • Shows how much I know about "modern" ES ... I had no idea it could interpolate variables. – Lightness Races in Orbit Feb 08 '16 at 13:24
  • SO: [Is there a downside to using ES6 template literals syntax without a templated expression?](http://stackoverflow.com/q/37777677/1048572) – Bergi Nov 07 '16 at 18:29
  • @lxrec Needing the literal sequence `${` in a string is the rarest case of all, a lot rarer even than needing a literal backtick. Surely it's more of a risk that you might accidentally put `${..}` in a non-backticked string and think it's interpolated when it's not? – callum Oct 16 '18 at 19:40

1 Answers1

3

If your team uses backticked strings frequently enough for its benefits (template expansion, multiline strings, different escaping, tagged templates), then you'll probably make fewer mistakes by sticking with that one syntax. That's because (1) you'll be more used to those escaping rules, (2) you won't have to (remember to) change quotes and escapes when adding ${ } template placeholders, and (3) you won't digress to decide if it's worth converting a string literal. You'll also remember about tagged templates and thus be less likely to accidentally write a tagged string. You'll be in the rhythm of using backticked strings and they'll distract you less from everything else to think about.

On the other hand, if your team frequently touches library code or client-side code that mostly/exclusively uses ' and " string literals, then you'll need to remain cognizant of which source files require that syntax. Furthermore if you rarely use the new features of backticked strings, you might make fewer mistakes by writing backticked strings only when needed (although I wouldn't suggest switching a string back after removing placeholders).

Another factor is the level of support for backtick strings in your editor/IDE. Syntax coloring might reveal the ${expression} placeholders and template tags, making mistakes more visible. A refactor command might quickly convert between formats, removing one incentive to use backticked strings just in case you later add placeholders. OTOH if backticked strings confuse your editor/IDE, you might want to use them sparingly until fixing that.

[If we cared enough about the programming process, we'd test hypotheses like these, i.e. measure the alternatives.]

Jerry101
  • 5,367
  • 1
  • 15
  • 19