Most JavaScript (and TypeScript) developers know that the language allows expressing string literals using either double quotes (") or single quotes ('). Given that both ways of expressing strings are semantically equivalent, this leads to the question of which one is the “right” way.
Generally, when it comes to coding style, it is advisable to conform to the convention of the particular language you are dealing with (for example, using camelCase for methods in JavaScript, but PascalCase in C#).
Unfortunately, it appears that there is no official convention for string quotes when it comes to JavaScript. So, the next best thing we could do in deciding on the best style of quotes to use is to try and find out which convention is more common.
Looking at some popular JavaScript projects on GitHub, I noted that react, moment, and express all use single quotes for strings. However, another popular project, tslib, uses double quotes 🙄. So, while it would seem that single quotes is more common, this metric is not entirely conclusive.
The deciding factor that convinced me personally applies to web development using a JavaScript framework that uses HTML-templates, such as Angular or Vue.js. In particular, these frameworks allow us to use JavaScript expressions for HTML attribute values. Take for example the following:
Since HTML itself also happens to allow either double quotes or single quotes for delimiting attribute values, this kind of brings us back to the same debate. In the case of HTML attributes, however, I will always stick to double-quotes, since using single-quotes for attribute values is very uncommon and frankly just seems wrong.
So, given that we use double quotes for HTML attributes, the only way for us to use double quotes in a JavaScript expression would be like so:
which for obvious reasons is pretty much out of the question. We are therefore basically forced to use single quotes for any string literal inside of a JavaScript expression.
When it comes to coding conventions, applying a convention consistently is more important than using the “best” convention. If we are then going to use single quotes in JavaScript within HTML, we must do the same everywhere else for consistency’s sake. For this reason my personal final choice for JavaScript literals is to use single quotes.
Coding style tooling
Regardless of whether you are decided on using single quotes or double quotes in JavaScript, the more important issue is applying your convention consistently throughout the code base. ESLint is one tool that will help a great deal in enforcing a consistent coding style. You supply it with a config file specifying a list of rules describing your coding conventions, and it will indicate where your code is not conforming to the specified rules. See the following links to get started:
- ESLint Getting Started Guide
- TypeScript ESLint: tooling for adding TypeScript-support to ESLint
- ESLint Integrations: locate the plugin for adding ESLint support to your favourite IDE
Add the rule quotes: ['error', 'single'] to your .eslintrc.js to make ESLint enforce single quotes.
If you happen to have a lot of style transgressions in your code, know that some rule violations can be automatically fixed by ESLint (including strings literals using the wrong type of quote). Just run the eslint command including the --fix option, like so (adjust the --ext option based on whether your code is in JavaScript or TypeScript):
eslint -c .eslintrc.js --fix --ext .js ./
I can also highly recommend Prettier for maintaining a consistent coding style and fixing up existing source code.
Which one of the quote-styles you settle on using in your JavaScript / TypeScript code is not nearly as important as actually committing to that and applying the rule consistently. Consistent application of coding conventions is not to be underestimated since it can significantly reduce the cognitive overhead when reading the code. The use of tooling such as ESLint and Prettier can help a lot in ensuring the coding style remains consistent even with many developers contributing to the code base.
Latest comments (0)