Когда мне следует использовать двойные или одинарные кавычки в JavaScript?
console.info("double"); против console.info('single');
Я вижу все больше и больше библиотек JavaScript, использующих одинарные кавычки при обработке строк. Каковы причины использовать одно вместо другого?
Я думал, что они в значительной степени взаимозаменяемы.
Как насчет этого Райана? alert("It's \"game\" time."); или alert('It\'s "game" time.');?
Если всегда используются одинарные кавычки, а иногда и двойные кавычки, где литерал содержит одинарные кавычки, тогда нам придется набирать гораздо меньше кнопок Shift, и наш левый мизинец будет благословлять. Но да, как сказал @arne, для JSON следует использовать двойные кавычки.
Одиночные кавычки легче сделать, когда вы используете европейскую клавиатуру (двойные кавычки - это Shift + 2, что не так приятно, как нажатие одной клавиши на правый мизинец).
@Arne Не существует такой вещи, как "европейская клавиатура". Например. Немецкая раскладка требует сдвига для обоих типов котировок. (Но одинарные кавычки проще.)
Не относитесь к ним религиозно (верьте, что один лучше другого), используйте тот, который избегает необходимости экранировать вашу строку, если это возможно, так как это будет легче читать. Если вы работаете с существующим кодом, используйте существующее соглашение, если оно есть.
Прочитав все комментарии, зная, что я «должен» выбрать лучший метод, и зная, что я трачу дни и дни на кодирование в javascript, я ЕДИНСТВЕННЫЙ человек, который когда-либо ловил себя, используя двойные кавычки в одной строке и одинарные кавычки на следующая строка без уважительной причины, даже не задумываясь об этом? Однако комментарии об использовании двойных кавычек для JSON важны, поэтому я рад, что случайно набрал свой вопрос в Google и наткнулся на него. :)
Если вы создаете свой JS на другом языке программирования, это может повлиять на ваш выбор. Например, из C, который использует двойные кавычки для своих собственных строк, используйте одинарные кавычки для вашего JS. Для Delphi все наоборот. И так один ...
Взглянув на это с другой точки зрения ... использование одинарных кавычек сокращает количество нажатий клавиш. Так как вам не нужно нажимать клавишу "Shift" ....: P
Если вы часто встраиваете HTML в строки, предпочтительнее использовать одинарные кавычки, это одна из причин, по которой Руководство по стилю Google рекомендует "более"
Одиночные кавычки лучше двойных, потому что они используют вдвое меньше пикселей и, следовательно, быстрее отображаются в вашем текстовом редакторе.
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 43
Наиболее вероятная причина использования single vs. double в разных библиотеках - предпочтения программиста и / или согласованность API. Помимо единообразия, используйте то, что лучше всего подходит для струны.
Использование другого типа цитаты в качестве литерала:
alert('Say "Hello"');
alert("Say 'Hello'");
Это может быть сложно:
alert("It's \"game\" time.");
alert('It\'s "game" time.');
Другой вариант, новый в ECMAScript 6, - это литералы шаблонов, в котором используется символ обратная кавычка:
alert(`Use "double" and 'single' quotes in the same string`);
alert(`Escape the \` back-tick character and the \${ dollar-brace sequence in a string`);
Шаблонные литералы предлагают чистый синтаксис для: интерполяции переменных, многострочных строк и т. д.
Обратите внимание, что JSON формально указан для использования двойных кавычек, что, возможно, стоит рассмотреть в зависимости от системных требований.
Важный момент, на который следует обратить внимание со всеми соглашениями о коде - определите его один раз и придерживайтесь его. IOW, не используйте двойные кавычки где-то и одинарные кавычки где-то.
@Cerebrus - Я думаю, гибкость здесь в порядке. Обязательно выберите предпочтительный стиль, но если вам нужно отойти от стиля, чтобы избежать экранирования множества кавычек в одной строке. Я бы с этим согласился.
Я не думаю, что есть причина быть последовательной в этом вопросе. Ни у одного из них нет преимуществ, и я не думаю, что читабельность действительно зависит от того, используете ли вы 'в одном месте и' в другом.
@Olly Hicks, интересный тест !! На самом деле одинарные кавычки в Chrome 13 (OSX) в несколько раз быстрее двойных кавычек. Интересно...
Javascript был разработан для веб-программистов, и его создатели хотели, чтобы он был как можно более простым и гибким. Поэтому я думаю, что неограниченные типы данных и гибкость, такие как объявление строки с одинарными и двойными кавычками, являются результатом этого.
Sublime Linter жалуется на двойные кавычки в строках, поэтому я начал использовать одинарные кавычки для строк.
Проблема с согласованностью заключается в том, что в настоящее время люди часто повторно используют фрагменты кода из Интернета или других проектов, поэтому рефакторинг всего «to» или наоборот после каждого копирования-> вставки может вызвать некоторые ошибки, если вы испортите экранирование. Я бы хотел, чтобы весь Интернет был последовательным в отношении цитат в Javascript ...
@Olly Hicks, я вижу значительную разницу во времени для Chrome (51), но, как ни странно, есть пара странных вещей: 1. Если я нажимаю кнопку запуска несколько раз, разница между двумя таймингами уменьшается до 0 (а иногда двойные кавычки быстрее!). 2. Если я сначала поставлю тест на двойные кавычки, разница во времени будет близка к нулю.
Немного не по теме, но если бы люди использовали правильную типографику, многие из этих дискуссий о побеге были бы устаревшими: alert('It’s “game” time') против alert("It’s “game” time") - не имеет значения. Вам нужно будет убежать только в (редких) случаях, когда действительно подходит одинарный или двойной штрих-код ', ".
Последовательность действительно имеет первостепенное значение. Что меня раздражает, так это то, что программист изначально выбрал использование одинарных кавычек в JS. Если вы используете Javascript, вы также, вероятно, работаете с HTML, CSS и JSON, и все они используют двойные кавычки. Поэтому первоначальный выбор `` предпочтения программиста '' использовать одинарные кавычки в JS для `` согласованности '' кажется неискренним, если он пренебрегает согласованностью с самого начала, используя другой стиль цитаты для существующих HTML, CSS и JSON, с которыми вы будете работать как программист JS.
@DarrenEvans Я стандартизировал одинарные кавычки для строк JS потому что HTML использует двойные кавычки ... someElement.innerHTML = '<div class = "something">etc</div>'; vs someElement.innerHTML = "<div class=\"something\">etc</div>";
В настоящее время такие инструменты, как ESlint, применяют его. Итак, если у вас есть (и, вероятно, вам следует их использовать) некоторые соглашения о стилях, вам даже не нужно задавать себе такой вопрос, он отформатирует их за вас. ^^
Есть люди, которые утверждают, что видят разницу в производительности: ветка старого списка рассылки. Но я не мог найти ни одного из них для подтверждения.
Главное - посмотреть, какие кавычки (двойные или одинарные) вы используете внутри своей строки. Это помогает снизить количество побегов. Например, когда вы работаете с HTML-содержимым внутри своих строк, проще использовать одинарные кавычки, так что вам не нужно избегать всех двойных кавычек вокруг атрибутов.
Хотя атрибуты тоже можно заключать в одинарные кавычки :)
Ваше право, я думал, что xml и xhtml предписывают двойные кавычки, окружающие атрибуты, но одинарные кавычки разрешены.
Строго нет никакой разницы, поэтому это в основном вопрос вкуса и того, что находится в строке (или если сам код JavaScript находится в строке), чтобы количество экранирований было небольшим.
Легенда о разнице в скорости может быть взята из мира PHP, где две кавычки имеют разное поведение.
И Руби, могу добавить. Python ведет себя так же, как JavaScript: нет разницы между одинарными / двойными кавычками.
Что ж, несколько лет спустя мы используем одинарные кавычки везде в нашем JS (на самом деле TS) коде (ну, конечно, обратные кавычки). Это хорошо сочетается с двойными кавычками, используемыми в HTML, когда у вас есть код JS / TS в шаблоне (например, в Angular).
Строго говоря, разницы в значениях нет; так что выбор сводится к удобству.
Вот несколько факторов, которые могут повлиять на ваш выбор:
- Домашний стиль: некоторые группы разработчиков уже используют то или иное соглашение.
- Требования на стороне клиента: будете ли вы использовать кавычки в строках? (См. Ади ответ.)
- Серверный язык: люди VB.NET могут использовать одинарные кавычки для JavaScript, чтобы сценарии могли быть построены на стороне сервера (VB.NET использует двойные кавычки для строк, поэтому строки JavaScript легко отличить, если они используют одиночные цитаты).
- Код библиотеки: если вы используете библиотеку, в которой используется определенный стиль, вы можете подумать об использовании того же стиля самостоятельно.
- Личные предпочтения: вы можете подумать, что тот или иной стиль выглядит лучше.
Неправда, ' - это 00100111 в двоичном формате, а " - это 00100010 в двоичном формате. Таким образом, двойные кавычки занимают половину меньше энергии для хранения, чем одинарные. Вот в чем разница.
Разница чисто стилистическая. Раньше я был нацистом в двойных кавычках. Теперь я использую одинарные кавычки почти во всех случаях. Нет никакой практической разницы, кроме того, как ваш редактор выделяет синтаксис.
Никакой практической разницы? Вы можете доказать это?
Бремя доказывания лежит на парне, утверждающем, что есть разница, а язык - нет.
Мудрость; язык не определяет разницу, что означает, что нет никакой разницы синтаксический. Однако, похоже, существует разница между браузерами, которая, по-видимому, указывает на влияние на производительность: stackoverflow.com/questions/242813/… Люди, которые говорят, что не имеет значения, какие кавычки вы используете, говорят о синтаксисе. Я говорю о практической реализации в разных браузерах.
Я прочитал ваш комментарий в другой ветке. Ты серьезно? Насколько быстрее JavaScript, использующий двойные кавычки? 0,00001 секунды на строку? Я думаю, что бремя доказательства лежит на вас, чтобы показать тесту, где имеет какое-либо существенное значение, используются ли двойные или одинарные кавычки. «Можно подумать» - это не доказательство. Кстати, я всегда использовал двойные кавычки, пока не заметил, что весь JavaScript в виджетах Apple Dashboard заключен в одинарные кавычки. Если этого хватит для Apple ...
Раздел 7.8.4 Спецификация описывает буквальную строковую нотацию. Единственное отличие состоит в том, что DoubleStringCharacter - это «SourceCharacter, но не в двойных кавычках», а SingleStringCharacter - «SourceCharacter, но не в одинарных кавычках». Итак, разницу Только можно продемонстрировать следующим образом:
'A string that\'s single quoted'
"A string that's double quoted"
Так что это зависит от того, сколько экранирования цитат вы хотите сделать. Очевидно, то же самое относится и к двойным кавычкам в строках с двойными кавычками.
@Gareth: Я не говорил о спецификациях, я говорил о возможном влиянии на производительность. stackoverflow.com/questions/242813/…
если вы добавляете в код достаточно апострофов, чтобы компенсировать количество нажатий shift + ', то вы делаете это неправильно.
А как насчет "{\"name\": \"Peter\"}" против '{"name": "Peter"}'? По общему признанию, вы могли бы сказать, что это та же разница, но она определенно повлияет на ваше решение иначе, чем в примере выше.
@MathiasBynens - это интересное наблюдение, которое не было актуальным как минимум год, а может быть, и шесть лет.
Для апострофа следует использовать U + 2019, а не вертикальную одинарную кавычку.
@MathiasBynens не знаю, что вы думаете через 9 лет .. но я бы сказал, что разница выполнение не учитывается, как Спецификация, поскольку это вызывает (вызвало?) Небольшие проблемы с производительностью в некоторых версиях браузеров, возвращающих ожидаемые значения. Если это ошибка, вызывающая неожиданное поведение, стоит отметить.
Хочу сказать, что разница чисто стилистическая, но я действительно сомневаюсь. Рассмотрим следующий пример:
/*
Add trim() functionality to JavaScript...
1. By extending the String prototype
2. By creating a 'stand-alone' function
This is just to demonstrate results are the same in both cases.
*/
// Extend the String prototype with a trim() method
String.prototype.trim = function() {
return this.replace(/^\s+|\s+$/g, '');
};
// 'Stand-alone' trim() function
function trim(str) {
return str.replace(/^\s+|\s+$/g, '');
};
document.writeln(String.prototype.trim);
document.writeln(trim);
В Safari, Chrome, Opera и Internet Explorer (протестированных в Internet Explorer 7 и Internet Explorer 8) это вернет следующее:
function () {
return this.replace(/^\s+|\s+$/g, '');
}
function trim(str) {
return str.replace(/^\s+|\s+$/g, '');
}
Однако Firefox даст немного другой результат:
function () {
return this.replace(/^\s+|\s+$/g, "");
}
function trim(str) {
return str.replace(/^\s+|\s+$/g, "");
}
Одинарные кавычки заменены двойными кавычками. (Также обратите внимание, как пространство для отступов было заменено четырьмя пробелами.) Это создает впечатление, что по крайней мере один браузер выполняет внутренний синтаксический анализ JavaScript, как если бы все было написано с использованием двойных кавычек. Можно подумать, что Firefox требуется меньше времени на синтаксический анализ JavaScript, если все уже написано в соответствии с этим «стандартом».
Что, кстати, делает меня очень грустной пандой, поскольку я думаю, что одинарные кавычки выглядят намного лучше в коде. Кроме того, в других языках программирования их обычно использовать быстрее, чем двойные кавычки, поэтому это будет иметь смысл только в том случае, если то же самое применимо к JavaScript.
Заключение: Я думаю, нам нужно провести больше исследований по этому поводу.
Это могло бы объяснить Результаты теста Петра-Пауля Коха еще в 2003 году.
It seems that single quotes are sometimes faster in Explorer Windows (roughly 1/3 of my tests did show a faster response time), but if Mozilla shows a difference at all, it handles double quotes slightly faster. I found no difference at all in Opera.
2014: В современных версиях Firefox / Spidermonkey этого больше нет.
Если в одном браузере сделать это одним способом немного быстрее, а в другом - наоборот, похоже, единственное руководство, которое мы можем извлечь из этого, состоит в том, что мы должны делать то, что нам больше нравится, потому что некоторым это повредит. пользователей и помогать другим, и разница, скорее всего, будет незаметной. «Преждевременная оптимизация ...» и все такое.
Дело в том, что в одном браузере (Firefox) он может быть немного быстрее, в то время как в других браузерах это не влияет на производительность.
Я не понимаю, насколько важен здесь способ распечатки функций Firefox. Это не совсем ответ на вопрос.
@ChristopherJamesCalo Вы действительно читали ответ? «[…] Создается впечатление, что по крайней мере один браузер выполняет внутренний синтаксический анализ JavaScript, как если бы все было написано с использованием двойных кавычек. Можно подумать, что Firefox требуется меньше времени на синтаксический анализ JavaScript, если все уже написано в соответствии с этим «стандартом» ».
Прошу прощения, мой комментарий не был более конструктивным. Я только говорю, что то, как браузер выбирает отображение своего внутреннего представления синтаксиса, вероятно, очень мало связано с тем, как он анализируется, и поэтому, вероятно, не является причиной предпочитать один тип кавычек другому. С другой стороны, данные о производительности, сравнивающие время синтаксического анализа для одинарных и двойных кавычек в разных браузерах, были бы более убедительными.
@ChristopherJamesCalo Я просто отвечаю на другие комментарии здесь, в которых утверждается, что оба они одинаковы и нет никакой разницы, кроме синтаксиса.
Я не думаю, что вам следует выбирать стиль кодирования, основанный на небольшой разнице в скорости синтаксического анализа браузера. Парсеры Javascript меняются, и если в одном он быстрее, а в другом медленнее, это не совсем оптимизация, верно? Я считаю, что если вы хотите оптимизировать свой код, вы, вероятно, можете сделать более важные вещи, чем изменение кавычек.
@RenaatDeMuynck Я никогда не говорил, что один быстрее другого - я просто задумался над вопросом. В любом случае, это не должно влиять на чей-либо стиль программирования, но все же интересно об этом подумать.
Это потрясающий ответ, отрыв от остальных, которые просто щебечут: «Они такие же, они такие же» ... Вы сказали «Кроме того, в других языках программирования они обычно используются быстрее, чем двойные кавычки», Могу я спросить, на каких языках? Я использовал обычные языки, такие как Java и C#, никогда не встречал ни одного другого, кроме JS, который принимает строковые литералы в одинарных кавычках. Одиночные кавычки обычно используются только для символьных констант (допускается только один символ).
@ADTC Я имел в виду PHP. эта статья утверждает, что одинарные кавычки быстрее двойных, потому что PHP должен интерпретировать переменные в строковых значениях с двойными кавычками. Позже я слышал, что это неправда (больше?).
Спасибо за ответ. Я не сделал ничего особенного в PHP, и мне это не нравится. Предпочитаю JSP, так как я хорошо знаком с Java. Ни разу не трогал ASP: /. В любом случае я думал, что вы имеете в виду язык, похожий на Java, C# и т. д., Потому что я не встречал такого случая.
AFAIK это было исправлено в Firefox 17, Firefox раньше выполнял декомпиляцию при выполнении .toString, но теперь он возвращает исходную копию. В современном Firefox этой проблемы не будет.
Не знаю о разнице в скорости. Но я хотел бы отметить, что «Создается впечатление, что по крайней мере один браузер выполняет внутренний синтаксический анализ JavaScript, как если бы все было написано с использованием двойных кавычек». ерунда. Он не разбирается, как если бы он был написан в двойных кавычках. То есть он превратил свое внутреннее представление (которое просто хранит строку, а не кавычки) в удобочитаемую версию, для которой используется один набор кавычек. Во всяком случае, согласно комментарию Бенджамина, это, похоже, изменилось.
@ADTC Я знаю, что это старый пост, но я просто хотел бы добавить, что PowerShell также имеет различие в том, как он обрабатывает строки с одинарными и двойными кавычками. Когда вы используете одинарные кавычки, вы указываете буквальную строку, а использование двойных кавычек заставляет PS выполнять интерполяцию строк, разрешая переменные внутри строки. Таким образом, я предполагаю, что одинарные кавычки, вероятно, быстрее (хотя на самом деле это может быть незаметно), и я думаю, что способ их представления различной семантики помогает, когда вы явно хотите интерполяцию или нет.
Не уверен, что это какая-то ошибка, которую я не вижу, или есть что-то странное при использовании атрибута pattern = в Chrome; У меня есть это в текстовом поле: pattern = '((12) | ([2-9] | 1 [01]?) (\ S (([13] \ / 4) | (1 \ / 2))) ?) \ "? ' Это работает. Не работает, если я использую двойные кавычки. Я пробовал двойное экранирование конечной кавычки в шаблоне, но это тоже не сработало.
@JeffLowery В HTML " экранирован как " или аналогичный, а не как \".
На самом деле \ "допустимо в значении атрибута (когда я сказал текстовое поле, я имел в виду ввод type = text); как я уже сказал, приведенный выше шаблон работает в Chrome и Firefox, и я думаю, теперь я остановлюсь на примере jsFiddle ... может также попробовать & quot;.
@JeffLowery Конечно pattern='\"' действителен, но люфт там бесполезен. jsfiddle.net/bL37n14j/3
Я думаю, важно не забывать, что, хотя в Internet Explorer может быть не установлено никаких расширений / панелей инструментов, в Firefox могут быть установлены некоторые расширения (например, я просто думаю о Firebug). Эти расширения повлияют на результат теста.
Не то чтобы это действительно важно, поскольку браузер X быстрее получает стили элементов, тогда как браузер Y может быстрее отображать элемент холста (поэтому «производитель» браузера всегда имеет самый быстрый движок JavaScript).
Если вы используете встроенный JavaScript (возможно, «плохо», но избегаете этого обсуждения), я считаю, что кавычки не замужем - ваш единственный вариант для строковых литералов.
Например, это отлично работает:
<a onclick = "alert('hi');">hi</a>
Но вы не можете заключить «привет» в двойные кавычки с помощью любого известного мне метода экранирования. Даже ", который был бы моим лучшим предположением (поскольку вы избегаете кавычек в значении атрибута HTML), у меня не работает в Firefox. " также не будет работать, потому что на этом этапе вы выполняете экранирование для HTML, а не для JavaScript.
Итак, если название игры - согласованность, и вы собираетесь использовать встроенный JavaScript в частях вашего приложения, я думаю, что одинарные кавычки являются победителем. Кто-нибудь, пожалуйста, поправьте меня, если я ошибаюсь.
Согласен с тем, что это, возможно, плохо, однако, если это нужно сделать, я почти уверен, что можно использовать кодировку в стиле URL, например, <a onclick = "alert(%22hi%22);">hi</a> - по памяти это работает, хотя, возможно, это было в атрибуте href вместо <a href = "javascript:alert(%22hi%22);">hi</a>
@PhiLho, вы правы насчет этого ... Я предполагал, что люди пишут атрибуты HTML с обычными двойными кавычками и не собираются ни (1) полностью преобразовывать все в одинарные кавычки, ни (2) смешивать и сопоставлять атрибуты в одинарных и двойных кавычках. Но да, ты прав, это законно
@Robert Я впечатлен тем, что работает. Очевидно, что это недопустимый JavaScript ... если бы вы запускали его в любом интерпретаторе, кроме браузера, это было бы синтаксической ошибкой. Но все равно интересно.
@Tom Lianza, конечно же, alert("hi") не является допустимым JavaScript. Но значения атрибутов закодированы. w3.org/TR/html4/intro/sgmltut.html#didx-attribute
В HTML также разрешено использование одинарных кавычек. Однако в XML (и XHTML) для атрибутов необходимо использовать двойные кавычки. Вот почему люди (включая меня) обычно используют только двойные кавычки для атрибутов.
Согласен с @Robert здесь. " - это правильный способ избежать двойных кавычек внутри атрибута HTML. Он отлично работает в Firefox. @Denilson, XML (и, следовательно, XHTML) допускает как одинарные, так и двойные кавычки. См. Литерал AttValue в спецификации XML по адресу w3.org/TR/REC-xml/#d0e888.
@Pacener: Потому что это не так. В HTML существует соглашение о заключении атрибутов в двойные кавычки.
Что касается единственный вариант и этого конкретного примера, вы можете использовать <a onclick = "alert(/hi/);">hi</a>, который также добавляет эти аккуратные символы / вокруг строкового литерала.
Я бы использовал двойные кавычки, когда нельзя использовать одинарные кавычки, и наоборот:
"'" + singleQuotedValue + "'"
'"' + doubleQuotedValue + '"'
Вместо:
'\'' + singleQuotedValue + '\''
"\"" + doubleQuotedValue + "\""
А как насчет строки, содержащей как одинарные, так и двойные кавычки, например O'rea "lly
В JavaScript нет разницы между одинарными и двойными кавычками.
Спецификация важна:
Может быть, разница в производительности есть, но она абсолютно минимальна и может измениться в любой день в зависимости от реализации браузеров. Дальнейшее обсуждение бесполезно, если ваше приложение JavaScript не состоит из сотен тысяч строк.
Это как эталон, если
a=b;
быстрее чем
a = b;
(лишние пробелы)
сегодня в определенном браузере и платформе и т. д.
без пробелов быстрее. меньше символов для синтаксического анализа в строке. :п
@pilavdzice: Да, но насколько это важно? Это всего на 0,0057% быстрее?
В конце концов, это можно сделать с помощью Webpack или подобного ему перед отправкой в производство (во время сборки), нет необходимости в подобных рассуждениях при кодировании. : D
Я пробовал это примерно 20 раз. И похоже, что двойные кавычки примерно на 20% быстрее.
Самое интересное, что если вы измените часть 2 и часть 1, одинарные кавычки будут примерно на 20% быстрее.
//Part1
var r='';
var iTime3 = new Date().valueOf();
for(var j=0; j<1000000; j++) {
r+='a';
}
var iTime4 = new Date().valueOf();
alert('With single quote : ' + (iTime4 - iTime3));
//Part 2
var s = "";
var iTime1 = new Date().valueOf();
for(var i=0; i<1000000; i++) {
s += "a";
}
var iTime2 = new Date().valueOf();
alert('With double quote: ' + (iTime2 - iTime1));
Другими словами, вы обнаружили, что более поздний код работает быстрее всего. Это проблема при проведении микротестов. Вы должны учитывать, что движок JS оптимизирует код во время его выполнения. (Вы увидите тот же эффект при тестировании Java из-за того, как работает JIT.)
первая новая дата медленная, добавьте var dummy_date = new Date() в начало
Уровень микрооптимизации здесь настолько глуп, что вы также можете утверждать, что одинарные кавычки вводятся быстрее, что приводит к более быстрой разработке.
Если вы имеете дело с JSON, следует отметить, что, строго говоря, строки JSON должны заключаться в двойные кавычки. Конечно, многие библиотеки также поддерживают одинарные кавычки, но у меня были большие проблемы в одном из моих проектов, прежде чем я понял, что одинарное цитирование строки на самом деле не соответствует стандартам JSON.
Это очень актуально при работе с jQuery.ajax, вызывающим службу ASP.NET (веб-служба, метод страницы или MVC).
В именах свойств в пределах строки JSON должны быть заключены в двойные кавычки, но строка JSON в целом может быть заключена в одинарные кавычки: var jsonString = '{"key1":"value1"}'; (не то чтобы я рекомендовал вручную создавать JSON.)
Я также нашел это очень актуальным при создании файлов package.json для node.js. jsonlint.com можно использовать для проверки json.
Это лучший аргумент в пользу использования двойных кавычек. JSON должен иметь двойные кавычки. Другие ответы в основном дают совет «быть последовательным», что означает, что если какая-либо часть языка может реально использовать двойные кавычки, вы должны постоянно использовать эти двойные кавычки.
Это также актуально при работе с несколькими языками, где почти все другие языки (Java, C, C++, ...) используют двойные кавычки для строк и одинарные кавычки для символов. Я предпочитаю использовать одинаковые кавычки по всем направлениям и поэтому придерживаюсь двойных кавычек для JS. С годами слепого набора лишняя клавиша для сдвига для двойных кавычек совершенно неуместна, и если ваше кодирование ограничено вашим набором текста, вам нужно практиковаться в правильном вводе.
Мне нравится комментарий Лоуренса Дола, потому что именно так я работаю. Может ли кто-нибудь указать, где в стандарте json я могу найти утверждение Арне о том, что строго поддерживаются только двойные кавычки?
@ mister270: json.org В частности, определение строки: «Строка представляет собой последовательность из нуля или более символов Юникода, заключенных в двойные кавычки с использованием экранирования обратной косой черты».
Меньше беспорядка в пикселях == лучше
Обратите внимание, что это относится к типу данных JSON, а не к POJSO, которые создаются в самом JavaScript, который принимает строки без кавычек, строки с одинарными кавычками и строки с двойными кавычками в качестве ключей.
@JoshfromQaribou На самом деле я бы сказал наоборот. Если действительный JSON требует двойных кавычек, тогда строки в вашем JavaScript должны использовать одинарные кавычки, поскольку это позволяет вам без проблем заключать строки JSON в кавычки.
@sdgfsdh Я сам везде использую одинарные кавычки. Я просто указал на то, что если вы используете их вместе, этот подход имеет смысл. Я действительно думаю, что двойные кавычки кажутся немного устаревшими, поскольку они имели смысл во времена хакерства JSONP, но теперь, когда у нас есть правильный CORS, мы должны уважать JSON как собственный тип файла. Есть и другие вещи, которые доставят вам неприятности, если вы попытаетесь относиться к JSON, как к ecma (все равно не цитируемые реквизиты, конечные запятые)
Как отмечает @JoshfromQaribou, эта точка JSON затрагивает главную причину использования одинарных кавычек: JSON - это не JavaScript. JavaScript легко спутать с окружающим кодом / синтаксисом, таким как JSON или Java, C, ASP, CF (на стороне сервера). Использование одинарных кавычек может помочь прояснить, на каком языке (и местонахождении: на стороне клиента или на стороне сервера) он находится. Я настоятельно рекомендую использовать одинарные кавычки в JavaScript, чтобы помочь отличить код на стороне сервера, очень поучительный шаблон для новичков, но также полезный для старых парней , и JSON - еще один прекрасный пример.
@CrisMooney, и когда люди пытаются использовать одинарные кавычки в JSON, Java, C, ASP и т. д., И их код не компилируется и тому подобное, потому что им было рекомендовано использовать одинарные кавычки в JavaScript вместо того, чтобы оставаться последовательными на разных языках ... Что тогда? Javascript не является JSON, но это не означает, что он должен быть полностью хипстерским на других языках. Я не знаю ни одного неэзотерического языка, который заставлял бы использовать одинарные кавычки для строк.
После прочтения всех ответов, в которых говорится, что это может быть быстрее или может иметь преимущества, я бы сказал, что двойные кавычки лучше или могут быть быстрее, потому что Компилятор Google Closure преобразует одинарные кавычки в двойные кавычки.
Вы знаете, почему он это делает?
Я не знаю. Может быть, это соглашение о кодировании и ничего особенного.
Некоторый контекст для Компилятор Google Closure: "Closure Compiler - это инструмент, позволяющий ускорить загрузку и выполнение JavaScript за счет удобства чтения человеком. Он не компилирует из JavaScript в машинный код, а, скорее, из JavaScript в более эффективный JavaScript. Он анализирует JavaScript, анализирует его, удаляет мертвый код и перезаписывает и минимизирует то, что осталось. Он также проверяет синтаксис, ссылки на переменные и типы и предупреждает об общих ошибках JavaScript. Он поддерживает перенос некоторых ECMAScript 6 "
Еще одна вещь, которую вы, возможно, захотите рассматривать как причину перехода от двойных кавычек к одинарным, - это рост популярности серверных скриптов. При использовании PHP вы можете передавать переменные и анализировать функции JavaScript, используя строки и переменные в PHP.
Если вы напишете строку и используете двойные кавычки для своего PHP, вам не придется избегать одинарных кавычек, и PHP автоматически получит значение переменных для вас.
Пример: мне нужно запустить функцию JavaScript, используя переменную с моего сервера.
public static function redirectPage( $pageLocation )
{
echo "<script type='text/javascript'>window.location = '$pageLocation';</script>";
}
Это избавляет меня от лишних хлопот, связанных с объединением строк, и я могу эффективно вызывать JavaScript из PHP. Это только один пример, но это может быть одной из нескольких причин, по которым программисты по умолчанию используют одинарные кавычки в JavaScript.
The most important feature of double-quoted strings is the fact that variable names will be expanded. See string parsing for details.
+1, я делаю это в своем проекте MVC.Net, чтобы двойные кавычки из C# не мешали одинарным кавычкам из javascript и наоборот.
Я думаю, что если вы пишете JavaScript на своей странице из метода класса PHP, у вас будут большие проблемы.
Технически разницы нет. Это только вопрос стиля и условностей.
Дуглас Крокфорд рекомендует использовать одинарные кавычки для внутренних строк и двойные кавычки для внешних (под внешними мы подразумеваем те, которые будут отображаться пользователю приложения, например, сообщения или предупреждения).
Я лично слежу за этим.
ОБНОВЛЕНИЕ: похоже, что г-н Крокфорд изменил мнение и теперь рекомендует использовать двойные кавычки повсюду :)
Дуглас Крокфорд против JQuery. Выбрать свой яд.
Что Крокфорд рассуждает по этому поводу?
Я следую этому соглашению. Это больше личное предпочтение. Мне нравится использовать строки в одинарных кавычках для внутренних вещей, таких как селекторы jQuery и / или таких вещей, как getElementById ('id');, мне просто нравится, как это выглядит с одинарными кавычками. Но переключитесь на двойные кавычки для внешнего текста, поскольку он часто может содержать внутренние кавычки в тексте. Кроме того, это позволяет легко определить и различить внешние и внутренние строки, если вы пытаетесь найти ошибку в одной или другой.
По состоянию на апрель 2016 года Дуглас Крокфорд теперь рекомендует использовал только двойные кавычки, учитывая, что на практике многим разработчикам трудно использовать дихотомию внутреннего и внешнего.
Да, см. эта презентация (на 10 мин 08 сек).
@Thunderforge: Эта ссылка (фактически) не работает. Google+ был закрыт в 2019 году.
@PeterMortensen Г-н Крокфорд объяснил, что теперь он считает, что двойные кавычки всегда должны быть выбором, поскольку они находятся в паре со строковой нотацией в JSON. Я думаю это очень веский аргумент
Для использования кода JavaScript на разных языках я обнаружил, что одинарные кавычки постоянно требуют меньше настройки кода.
Двойные кавычки поддерживают многострочные строки.
Двойные кавычки не поддерживают многострочные строки в JavaScript.
они делают, если вы ставите обратную косую черту на каждом eol
Это не гарантируется для всех браузеров / систем, потому что этого нет в спецификации. Это не стандарт, которому кто-либо должен следовать, поэтому я бы с осторожностью делал это в целях безопасности. Примечание: я не голосовал против вас, это сделал кто-то другой. ;)
Чтобы добавить, это также может сломать некоторые минификаторы.
но это важно, если вы хотите выполнить какое-то буквальное метапрограммирование, такое как xhr-ing предопределенного сценария для вашего сайта с помощью SSL, и при этом сохранить читаемость
Если вам нужны многострочные строки в JS из ES6, см. tc39wiki.calculist.org/es6/template-strings
Надеюсь, я не добавляю что-то очевидное, но я боролся с Джанго, Аякс и JSON по этому поводу.
Предполагая, что в вашем HTML-коде вы используете двойные кавычки, как обычно, я настоятельно рекомендую использовать одинарные кавычки для остальной части в JavaScript.
Так что я согласен с с Ади, но с некоторой осторожностью.
Мой итог:
В JavaScript это, вероятно, не имеет значения, но как только вы встраиваете его в HTML или что-то подобное, у вас начинаются проблемы. Вы должны знать, что на самом деле экранирует, читает, передает вашу строку.
Мой простой случай был:
tbox.innerHTML = tbox.innerHTML + '<div class = "thisbox_des" style = "width:210px;" onmouseout = "clear()"><a href = "/this/thislist/'
+ myThis[i].pk +'"><img src = "/site_media/'
+ myThis[i].fields.thumbnail +'" height = "80" width = "80" style = "float:left;" onmouseover = "showThis('
+ myThis[i].fields.left +','
+ myThis[i].fields.right +',\''
+ myThis[i].fields.title +'\')"></a><p style = "float:left;width:130px;height:80px;"><b>'
+ myThis[i].fields.title +'</b> '
+ myThis[i].fields.description +'</p></div>'
Вы можете увидеть 'в третьем поле showThis.
Двойные кавычки не работали!
Понятно почему, но также понятно, почему мы должны придерживаться одинарных кавычек ... Я думаю ...
Этот случай представляет собой очень простое встраивание HTML, и ошибка была сгенерирована простым копированием / вставкой из кода JavaScript с двойными кавычками.
Итак, чтобы ответить на вопрос:
Старайтесь использовать одинарные кавычки внутри HTML. Это может избавить от пары проблем с отладкой ...
Я столкнулся с аналогичной проблемой с интерполяцией строк в ES6 (обратные кавычки). Моя система сборки скомпилировала его в строку с двойными кавычками, что нарушило заголовок Auth, который работал с одинарными кавычками!
В основном это вопрос стиля и предпочтений. В других ответах есть несколько довольно интересных и полезных технических исследований, поэтому, возможно, единственное, что я могу добавить, - это предложить небольшой мирской совет.
Если вы кодируете в компании или команде, потом, вероятно, неплохо следовать «домашнему стилю».
Если вы один взламываете несколько побочных проектов, потом посмотрите на нескольких выдающихся лидеров сообщества. Например, допустим, вы попали в Node.js. Взгляните на основные модули, например, Underscore.js или express, и посмотрите, какое соглашение они используют, и подумайте о том, чтобы следовать этому.
Если оба соглашения используются одинаково, потом соответствует вашим личным предпочтениям.
Если у вас нет личных предпочтений, потом подбросьте монету.
Если у тебя нет монеты, пиво потом на мне;)
Посмотрим, что делает ссылка.
Внутри jquery.js каждая строка заключена в двойные кавычки.
Итак, теперь я буду использовать строки в двойных кавычках. (Я использовал сингл!)
Почему это отклонено. Это вопрос стиля, и лучший стиль - быть последовательным и следовать за теми, кто был до вас.
+1 документация jQuery API тоже. Это была единственная причина, по которой я остановился на двойных кавычках. Лично я считаю, что ответы «все сводится к личным предпочтениям» немного ошибочны - лучше всего найти широко используемое соглашение и придерживаться его. И поскольку я могу копировать и вставлять примеры из jQuery (прямо или косвенно), я не хочу каждый раз заменять кавычки.
Возможно, jQuery не смог последовать за людьми до них (или действительно не заботился, как большинство других экспертов). ;)
Для меня, если я кодирую в редакторе Vim и если что-то заключено в одинарные кавычки, я могу дважды щелкнуть, чтобы выбрать Только текст в кавычках. С другой стороны, двойные кавычки включают в себя кавычки, которые меня раздражают, когда я хочу быстро скопировать и вставить.
Например. Двойной щелчок myVar в редакторе Vim копирует:> myVar < «myVar» буквально копирует:> «myVar» <и когда я вставляю, мне приходится удалять кавычки с обеих сторон.
Это настраивается в большинстве терминалов (например, gnome-terminal: Edit-> Profile-> General-> Select-by-word characters) и в gVim (superuser.com/a/387060/33415).
Как сказано в других ответах, они почти одинаковы. Но я постараюсь добавить еще.
- Некоторые эффективные алгоритмы используют символьные массивы для обработки строк. Эти алгоритмы (компилятор браузера и т. д.) Сначала увидят
"(# 34) перед'(# 39), что позволит сэкономить несколько циклов ЦП в зависимости от вашей структуры данных. "ускользает от двигателей анти-XSS
(1) звучит как чистое предположение. Эффективный токенизатор не будет использовать глупую структуру if 0x30 ... else if 0x31 ... else if .... Компилятор преобразовал бы переключатель в сбалансированное дерево ветвей (так сложно сказать, что дешевле, если вообще), или в таблицу переходов (так что все стоит одинаково). Есть и более странные способы, например, битовые уловки для поиска символа сразу во всем слове. В любом случае это было бы незначительным и не нужно учитывать при принятии решения о написании кода..
домыслы в лучшем случае. Я попытался найти это и зашел в тупик. Было бы интересно увидеть, где упоминается этот алгоритм
Я не уверен, актуально ли это в современном мире, но двойные кавычки использовались для контента, который требовал обработки управляющих символов, и одинарные кавычки для строк, которые этого не сделали.
Компилятор будет выполнять манипуляции со строкой для строки в двойных кавычках, оставляя строку в одинарных кавычках буквально нетронутой. Раньше это приводило к тому, что `` хорошие '' разработчики предпочитали использовать одинарные кавычки для строк, которые не содержали управляющих символов, таких как \n или \0 (не обрабатывались в одинарных кавычках), и двойные кавычки, когда им нужно было проанализировать строку (с небольшой затратой в CPU циклы обработки струны).
Дело не в том, что раньше все делалось так, а теперь - по-другому. В разных языках кавычки обрабатываются по-разному, а некоторые работают так, как вы описываете. Но это вопрос JavaScript. Одинарные и двойные кавычки обрабатываются в JavaScript одинаково (за исключением того, что позволяет использовать другой тип кавычек в строке без экранирования). Не может быть и речи о двойных кавычках, разрешающих управляющие символы или интерполяцию строк. JavaScript так не работает. Управляющие символы и escape-последовательности работают одинаково, какой бы тип кавычек вы ни использовали.
Как бывший программист Perl, я продолжаю думать об этом, хотя знаю, что это не имеет отношения к JS.
Если вы перепрыгиваете между JavaScript и C#, лучше всего научить свои пальцы общему соглашению - двойным кавычкам.
Нет лучшего решения; однако я хотел бы утверждать, что иногда двойные кавычки могут быть более желательными:
- Новички уже будут знакомы с двойными кавычками на своем языке.. В английском языке мы должны использовать двойные кавычки
"для обозначения отрывка цитируемого текста. Если бы мы использовали одинарную кавычку', читатель мог бы неверно истолковать ее как сокращение. Другое значение отрывка текста, окруженного', указывает на «разговорный» смысл. Имеет смысл оставаться в соответствии с уже существующими языками, и это, вероятно, может облегчить изучение и интерпретацию кода. - Двойные кавычки избавляют от необходимости избегать апострофов (как в сокращениях). Рассмотрим строку:
"I'm going to the mall", а не версию с экранированием:'I\'m going to the mall'. Двойные кавычки означают строку на многих других языках. Когда вы изучаете новый язык, например Java или C, всегда используются двойные кавычки. В Ruby, PHP и Perl строки в одинарных кавычках не подразумевают экранирования обратной косой черты, в то время как двойные кавычки их поддерживают.
Обозначение JSON записывается в двойные кавычки.
Тем не менее, как утверждали другие, очень важно оставаться последовательным.
Ваше первое мнение об английском языке не всегда верно и может измениться в зависимости от местности / дома. Печатные материалы обычно используют одинарные кавычки для речи и используют другое форматирование для больших блоков цитируемого текста. Ваше «разговорное» значение не является полезным определением цитат для выделения. К тому же англоговорящие пользователи в целом очень плохо используют кавычки и апострофы.
@JohnFerguson, только по этой причине, может быть желательно использовать двойные кавычки, чтобы сделать это различие (между апострофами и цитируемыми отрывками).
Я все о прагматизме. Из-за того, что 1 из 100 строк, которые я набираю или использую, имеет двойные кавычки, а многие, многие другие имеют апострофы, я использую двойные кавычки. В конце концов, тем не менее, вы должны использовать тип цитаты, который 1) уже используется в проекте, если вы новый разработчик проекта, или 2) используйте тот, который, по вашему мнению, имеет больше смысла.
Показательный пример - то, что я только что набрал (здесь несколько апострофов, без двойных кавычек;)
Чтобы добавить к третьему пункту @ user1429980, одинарные кавычки обозначают другой тип данных в Java и C.
Если вы создаете строки для JSON или HTML, вы должны использовать одинарные кавычки для строк, потому что все свойства JSON и все атрибуты HTML требуют двойных кавычек. Чтобы избежать их экранирования, в строке должны использоваться одинарные кавычки. Я считаю, что это наиболее распространенный сценарий, поскольку JavaScript имеет тенденцию немного работать с JSON и HTML.
@Triynko, не обязательно; использование одинарных кавычек в HTML вполне допустимо: let escapedHTML = "<section class='page-field'></section>". Для JSON вы должны использовать одинарные кавычки при построении, но в Javascript (контекст этого вопроса) вы, вероятно, никогда не столкнетесь с необходимостью сделать это, потому что вы просто создадите JSON с объектами.
Это убедило меня, и я хочу добавить к третьему пункту: «двойные кавычки означают строку во многих других языках». В Ruby строка может быть окружена одинарными или двойными кавычками, но в одинарных кавычках \ не интерпретируется как escape (как в JavaScript), поэтому использование двойных кавычек упрощает переход пользователя Ruby на JavaScript, где \ означает escape. . Однако ситуация в Python такая же, как и в JavaScript.
'легче спутать с `, поэтому придерживайтесь", чтобы вы могли лучше видеть ".
Лучше всего использовать двойные кавычки ("") вначале и одинарные кавычки (''), если необходимо, после. Причина в том, что если вы когда-либо будете использовать сценарии на стороне сервера, вы не сможете извлекать контент с сервера (например, SQL-запросы из базы данных), если вы используете одиночные кавычки вместо двойных.
Не уверен насчет последней части. Если приняты надлежащие меры для выхода из строки, чтобы предотвратить SQL-инъекцию (угроза безопасности), я думаю, что любая цитата приемлема. Символы не следует пропускать дословно.
Думаю, все дело в удобстве / предпочтении.
Я предпочитаю двойные кавычки, потому что они соответствуют тому, что есть в C#, и это моя среда, в которой я обычно работаю: C# + JavaScript.
Также одна из возможных причин двойных кавычек вместо одинарных заключается в следующем (я нашел в коде своих проектов): Французский или некоторые другие языки часто используют одинарные кавычки (например, английский), поэтому, если по какой-то причине вы закончите рендеринг строк со стороны сервера (что, как я знаю, является плохой практикой), то одиночная кавычка будет отображаться неправильно.
Вероятность использования двойных кавычек в обычном языке мала, и поэтому я думаю, что у него больше шансов что-то не сломать.
Говоря о производительности, цитаты никогда не будут вашим узким местом. Однако производительность в обоих случаях одинакова.
Говоря о скорости кодирования, если вы используете ' для разделения строки, вам нужно будет избегать кавычек ". Скорее всего, вам понадобится использовать " внутри строки. Пример:
// JSON Objects:
var jsonObject = '{"foo":"bar"}';
// HTML attributes:
document.getElementById("foobar").innerHTML = '<input type = "text">';
Затем я предпочитаю использовать ' для разделения строки, поэтому мне нужно экранировать меньше символов.
Одна (глупая) причина использования одинарных кавычек заключается в том, что они не требуют нажатия клавиши Shift для их ввода, тогда как двойные кавычки делают. (Я предполагаю, что средняя строка не требует экранирования, что является разумным предположением.) Теперь предположим, что каждый день я кодирую 200 строк кода. Может быть, в этих 200 строках у меня 30 цитат. Возможно, ввод двойной кавычки занимает на 0,1 секунды больше времени, чем ввод одинарной кавычки (потому что мне нужно нажать клавишу Shift). Тогда в любой день я теряю 3 секунды. Если я кодирую таким образом 200 дней в году в течение 40 лет, то я потрачу впустую 6,7 часа своей жизни. Пища для размышлений.
Я предполагаю, что вы имеете в виду только английскую раскладку клавиатуры ... У меня немецкая, мне нужно нажать Shift для обоих. В любом случае, я не понимаю, почему нажатие клавиши Shift увеличивает время процесса. Я нажимаю Shift левой рукой, а правой нажимаю клавишу кавычек. Это происходит одновременно, для меня разницы нет.
@codewandler По-прежнему приходится нажимать клавишу Shift, даже если вы можете нажимать ее параллельно с клавишей ". Это заставляет вас отвести палец от положения по умолчанию. Например, предположим, что вы печатаете: var description = "This is a \"quick\" test"; на английской клавиатуре. Для английской клавиатуры ваш мизинец должен перемещаться от левой клавиши Shift до клавиши Q в верхнем ряду вместо того, чтобы перемещаться от клавиши A к клавише Q. Другими словами, он должен перемещаться вдвое больше Я не уверен, где находятся клавиши на немецкой клавиатуре, но уверен, что есть аналогичный пример.
@codewandler Кроме того, необходимость набирать shift, даже если я могу сделать это параллельно, не позволяет левому мизинцу подготовиться к вводу следующего символа после «во всем, что вы печатаете.
Идея «траты времени» немного глупа, но идея меньшей эргономической нагрузки (особенно в эпоху синдрома туннельного туннеля и т.д.) дает хороший выигрыш, особенно в тех случаях, когда в остальном это не имеет значения. Учитывая более 1000 строк кода в день, это может сэкономить сотни ежедневных изгибов мизинца.
Что-то не так, если вы набираете буквально все. Есть копирование, вставка и изменение, текстовые шаблоны (слишком хорошо скрытые в Visual Studio), макросклавиатуры (физический), макросы клавиатуры и автоматизация в различных формах.
Если вы используете JSHint, это вызовет ошибку, если вы используете строку в двойных кавычках.
Я использовал его через скаффлхолдинг Yeoman в AngularJS, но, возможно, есть способ настроить это.
Кстати, когда вы преобразовываете HTML в JavaScript, проще использовать одинарные кавычки:
var foo = '<div class = "cool-stuff">Cool content</div>';
И, по крайней мере, JSON использует двойные кавычки для представления строк.
На ваш вопрос нет тривиального ответа.
Изменилась ли реализация jshint? поскольку демонстрационный веб-сайт, похоже, принимает либо без каких-либо предупреждений / ошибок, и я не могу найти никаких вариантов, чтобы ограничить использование jshint. Возможно, этот ответ устаревший или неточный?
если jshint вызывает ошибку для строки с двойными кавычками, это серьезно нарушено. Стандарт JavaScript определяет, что является правильным, а не какой-то сломанный линтер.
Если ваш источник JavaScript
elem.innerHTML = "<img src='smily' alt='It\'s a Smily' style='width:50px'>";
исходный код HTML будет:
<img src = "smiley" alt = "It's a Smiley" style = "width:50px">
Или для HTML5
<img src=smiley alt = "It's a Smiley" style=width:50px>
JavaScript позволяет использовать такие массивы:
var arr=['this','that'];
Но если вы сделаете его строковым, это будет из соображений совместимости:
JSON=["this","that"]
Я уверен, что это займет некоторое время.
Просто чтобы добавить свой два цента: работая как с JavaScript, так и с PHP несколько лет назад, я привык использовать одинарные кавычки, поэтому я могу вводить escape-символ (''), не экранируя его. Я обычно использовал его при вводе сырые струны с путями к файлам и т. д.
Как бы то ни было, мое соглашение привело к использованию одинарных кавычек в необработанных строках типа идентификатора, таких как if (typeof s == 'string') ... (в которых escape-символы никогда не будут использоваться - никогда), и двойных кавычках для тексты, таких как «Эй, как дела?» . Я также использую одинарные кавычки в комментариях как типографское соглашение, чтобы отображать имена идентификаторов. Это просто практическое правило, и я прерываю его только тогда, когда это необходимо, например, при вводе HTML-строк '<a href = "#"> like so <a>' (хотя вы также можете поменять кавычки здесь). Я также знаю, что в случае JSON для имен используются двойные кавычки, но за пределами этого лично я предпочитаю одинарные кавычки, когда экранирование никогда требуется для текста между кавычками - например, document.createElement('div').
Суть в том, как некоторые упоминали / упоминали, выбрать соглашение, придерживаться его и отклоняться только тогда, когда это необходимо.
Вы можете использовать одинарные или двойные кавычки.
Это позволяет, например, легко вкладывать содержимое JavaScript в атрибуты HTML без необходимости экранировать кавычки. То же самое и при создании JavaScript с помощью PHP.
Общая идея такова: по возможности используйте такие кавычки, которые вам не нужно будет избегать.
Меньше экранирования = лучший код.
При использовании CoffeeScript я использую двойные кавычки. Я согласен, что вам следует выбрать любой из них и придерживаться его. CoffeeScript дает вам интерполяцию при использовании двойных кавычек.
"This is my #{name}"
ECMAScript 6 использует обратные галочки (`) для строк шаблона. Для чего, вероятно, есть веская причина, но при кодировании может быть обременительно изменить символ строковых литералов с кавычек или двойных кавычек на обратные кавычки, чтобы получить функцию интерполяции. CoffeeScript может быть не идеальным, но использование одного и того же символа строковых литералов повсюду (двойные кавычки) и всегда возможность интерполировать - это хорошая функция.
`This is my ${name}`
Для меня обратный тик - явный победитель в этом конкурсе, (почти) отсутствие присутствия в общих текстовых строках, плюс интерполяция var
Одиночные цитаты
Я бы хотел, чтобы двойные кавычки были стандартом, потому что они иметь немного больше смысла, но я продолжаю использовать одинарные кавычки, потому что они доминируют на сцене.
Одиночные кавычки:
- Airbnb
- Хрюканье
- Gulp.js
- Node.js
- npm (хотя и не определен в руководство автора)
- Викимедиа
- WordPress
- Яндекс
Нет предпочтения:
Двойные кавычки:
- Машинопись
- Дуглас Крокфорд
- D3.js (хотя и не определен в
.eslintrc) - jQuery
Крокфорд теперь предпочитает двойные кавычки.
airbnb теперь предпочитает двойные кавычки
@SurajJain Source? Руководства по стилю Airbnb и Google по-прежнему указывают single как предпочтительный.
@OlegsJeremejevs github.com/jscs-dev/node-jscs/blob/master/presets/google.jso n Они не используют его, поэтому я подумал ... ссылка на Google выше, когда я открыл ее и увидел файл, они нигде не использовали одинарную кавычку
@SurajJain А, это конфигурации средства проверки стиля кода, написанные на JSON, который вообще не допускает одинарных кавычек. Их чтение - хороший способ сравнить варианты, сделанные в разных проектах.
@SurajJain Ну, Красноречивый JavaScript уважают. Мне не известно о чем-то подобном для CSS. В любом случае вы можете изучить онлайн-курсы (хороший случайный список, который я только что нашел).
Хорошо, спасибо, я сделаю это, и не запутайтесь, когда вы знаете все эти языки с синтаксисом и другими концепциями.
Facebook React использует одинарные кавычки источник
@styfle Спасибо, добавил eslint-config-fbjs-opensource.
Google теперь предпочитает одинарные кавычки
Ссылка Дугласа Крокфорда не работает (Google+ закрыт). Вот презентация (Конференция разработчиков ConFoo 2017).
Просто сохраняйте последовательность в том, что вы используете. Но не стоит снижать уровень комфорта.
"This is my string."; // :-|
"I'm invincible."; // Comfortable :)
'You can\'t beat me.'; // Uncomfortable :(
'Oh! Yes. I can "beat" you.'; // Comfortable :)
"Do you really think, you can \"beat\" me?"; // Uncomfortable :(
"You're my guest. I can \"beat\" you."; // Sometimes, you've to :P
'You\'re my guest too. I can "beat" you too.'; // Sometimes, you've to :P
Обновление ECMAScript 6
Использование синтаксис литерала шаблона.
`Be "my" guest. You're in complete freedom.`; // Most comfort :D
Examining the pros and cons
В пользу одинарных кавычек
- Меньше визуального беспорядка.
- Создание HTML: атрибуты HTML обычно разделяются двойными кавычками.
elem.innerHTML = '<a href = "' + url + '">Hello</a>';elem.innerHTML = "<a href='" + url + "'>Hello</a>";Более того, встроенный HTML обычно является анти-шаблоном. Предпочитаю шаблоны.
- Создание JSON: в JSON разрешены только двойные кавычки.
myJson = '{ "hello world": true }';Опять же, вам не нужно создавать JSON таким образом. JSON.stringify () часто бывает достаточно. Если нет, используйте шаблоны.
В пользу двойных кавычек
- Двойников легче обнаружить, если у вас нет цветовой кодировки. Как в журнале консоли или в какой-то настройке источника просмотра.
- Сходство с другими языками: в программировании оболочки (Bash и т. д.) Существуют строковые литералы в одинарных кавычках, но escape-последовательности внутри них не интерпретируются. C и Java используют двойные кавычки для строк и одинарные кавычки для символов.
- Если вы хотите, чтобы код был действительным JSON, вам нужно использовать двойные кавычки.
В пользу обоих
В JavaScript нет разницы между ними. Поэтому вы можете использовать все, что вам удобно в данный момент. Например, все следующие строковые литералы создают одну и ту же строку:
"He said: \"Let's go!\""
'He said: "Let\'s go!"'
"He said: \"Let\'s go!\""
'He said: \"Let\'s go!\"'Одинарные кавычки для внутренних строк и двойные для внешних. Это позволяет отличать внутренние константы от строк, которые должны отображаться пользователю (или записываться на диск и т. д.). Очевидно, вам следует избегать включения последнего в свой код, но это не всегда возможно.
Re "встроенный HTML": Вы имеете в виду "встроенный JavaScript"?
Для меня это просто вопрос время. Несколько миллисекунд теряются в моей жизни каждый раз, когда мне приходится нажимать клавишу Shift, прежде чем каждый раз я могу набирать ".
Я предпочитаю ' просто потому, что вам не нужно этого делать!
Помимо этого, вы можете экранировать ' внутри одинарных кавычек с помощью обратной косой черты \'.
console.info('Don\'t lose time'); // "Don't lose time"
Я использую одинарные кавычки большую часть времени, потому что при разработке на PHP одинарные кавычки никоим образом не меняются, а это то, что я хочу. Когда я использую
echo "$xyz";
В PHP вычисляется $ xyz, что мне и нужно нет. Поэтому я всегда использую ' вместо ", когда дело касается веб-разработки. Поэтому, когда дело касается PHP / JavaScript, я гарантирую, по крайней мере, последовательность строк.
К сожалению, это невозможно сделать в Java или Цель-C, где '' означает символ, а "" - строку. Но это другой вопрос.
Re «JScript»: Вы имеете в виду "JavaScript"?
Я использую "jscript" и "javascript" как взаимозаменяемые ... поскольку jscript является / был языком, разработанным Microsoft, является подмножеством javascript, но здесь различия не учитываются
Если вы используете PHP для генерации кода JavaScript, вам следует использовать следующее объявление.
let value = "<?php echo 'This is my message, "double quoted" - \'single quoted\' ?>";
Результат будет:
This is my message, "double quoted" - 'single quoted'
По некоторым причинам в PHP рекомендуется использовать одинарные кавычки, а не двойные.
Для нормального поведения в JavaScript рекомендуется использовать одинарные кавычки.
var value = 'This is my message';
document.getElementById('sample-text').innerHTML = value;<span id = "sample-text"></span>Лично я предпочитаю одинарные кавычки для удобства чтения. Если я весь день смотрю на код, легче увидеть слова, заключенные в одинарные кавычки, а не в двойные.
Легче читать, как показано здесь:
"легко читать"
"труднее читать"
"" труднее всего читать ""
Теперь, когда наступил 2020 год, мы должны рассмотреть третий вариант для JavaScript: единый обратный апостроф для всего.
Это можно использовать везде вместо одинарных или двойных кавычек.
Это позволяет вам делать все!
Вставьте в него одинарные кавычки: `Это здорово!`
Вставьте в него двойные кавычки: `Это" действительно "здорово!`
Использовать строковую интерполяцию: `Это" $ {лучше} ", чем здорово!`
Он позволяет использовать несколько строк: `
Этот
Делает
JavaScript
Лучше!
`
Это также не вызывает потери производительности при замене двух других: Обратные кавычки (``) медленнее, чем другие строки в JavaScript?
Я предпочитаю использовать одинарные кавычки, '. Его легче печатать и он лучше выглядит.
Также давайте помнить, что прямые кавычки (одинарные и двойные) - ошибка в хорошей типографике. Фигурные кавычки предпочтительнее, поэтому вместо экранирования прямых кавычек я предпочитаю использовать правильные символы.
const message = 'That\'s a \'magic\' shoe.' // This is wrong
const message = 'That’s a ‘magic’ shoe.' // This is correct
https://practicaltypography.com/straight-and-curly-quotes.html
Может кто-нибудь добавить функцию умных цитат в Visual Studio Code, пожалуйста?
А как насчет ... когда нужно использовать ... интерполяциядраматическая музыка.
что легче читать? alert («Пришло время игры»); or alert («Время игры»);