Когда использовать двойные или одинарные кавычки в JavaScript?


1969

console.log("double"); против console.log('single');

Я вижу все больше и больше библиотек JavaScript, использующих одинарные кавычки при обработке строк. Каковы причины использовать один над другим? Я думал, что они в значительной степени взаимозаменяемы.


125
что легче читать? alert («Время игры»); или оповещение («Это игровое время»);
Райан Миллер

591
Как насчет этого Райана? alert("It's \"game\" time.");или alert('It\'s "game" time.');?
Франциск

37
Если всегда используются одинарные кавычки и иногда двойные кавычки, где литерал содержит одинарную кавычку, то нам придется печатать гораздо меньше кнопок Shift, и левый мизинец даст нам благословения. Но да, как сказал @arne, для JSON следует использовать двойные кавычки.
IsmailS

9
Одиночные кавычки легче выполнять, когда вы используете европейскую клавиатуру (двойная кавычка - это Shift + 2, которая не так приятна, как удобное нажатие одной клавиши правой кнопкой мыши).
Арне

38
@Arne Нет такой вещи как "европейская клавиатура". Например, немецкая клавиатура требует сдвига для обоих типов кавычек. (Но одинарные кавычки проще.)
ANEves

Ответы:


1223

Наиболее вероятной причиной использования одинарного или двойного в разных библиотеках является предпочтение программиста и / или согласованность API. Помимо того, чтобы быть последовательным, используйте тот, который лучше всего подходит для строки.

Используя другой тип цитаты в качестве литерала:

alert('Say "Hello"');
alert("Say 'Hello'");

Это может быть сложно:

alert("It's \"game\" time.");
alert('It\'s "game" time.');

Другой вариант, новый в ES6, это литералы шаблона, которые используют back-tickсимвол:

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 формально указан для использования двойных кавычек, что может стоить учитывать в зависимости от системных требований.


85
Важный момент, который следует отметить со всеми соглашениями кода - определите его один раз и придерживайтесь его. IOW, не используйте двойные кавычки где-нибудь и одинарные кавычки в другом месте.
Cerebrus

170
@Cerebrus - я думаю, что гибкость в порядке с этим. Конечно, выберите предпочтительный стиль, но если вам нужно оторваться от стиля, чтобы сохранить множество кавычек в одной строке. Я был бы в порядке с этим.
Мартин Кларк

5
Я не думаю, что есть какая-то причина, чтобы быть последовательным в этом. Ни у одного из них нет никаких преимуществ, и я не думаю, что читаемость действительно влияет на то, используете ли вы «в одном месте» и «в другом»
cdmckay

2
@Olly Hicks, интересный тест !! Одиночные кавычки на самом деле в несколько раз быстрее, чем двойные кавычки здесь, в Chrome 13 (OSX). Интересно ...
Рикет

13
Немного не по теме, но если бы люди использовали правильную типографику, многие из этих дискуссий о побеге были бы устаревшими: alert('It’s “game” time')против alert("It’s “game” time")- не имеет значения. Вам нужно было бы избежать только в (редких) случаях, когда одинарный или двойной простой знак ', "на самом деле, уместен.
Jotaen

617

Если вы имеете дело с JSON, следует отметить, что строго говоря, строки JSON должны быть заключены в двойные кавычки. Конечно, многие библиотеки также поддерживают одинарные кавычки, но у меня были большие проблемы в одном из моих проектов, прежде чем я понял, что одиночные кавычки строки на самом деле не соответствуют стандартам JSON.


5
Это очень важно при работе с вызовом jQuery.ajax в службу ASP.NET (веб-служба, метод страницы или MVC).
Шмули

100
Имена свойств в строках JSON должны быть заключены в двойные кавычки, но строка JSON в целом может быть заключена в одинарные кавычки: var jsonString = '{"key1":"value1"}';(Не то, чтобы я рекомендовал вручную создавать JSON.)
nnnnnn

51
Вы не должны писать JSON вручную, если можете .stringify().
Камило Мартин

23
Это прямо здесь - лучший аргумент для того, чтобы всегда использовать двойные кавычки. JSON должен иметь двойные кавычки. Другие ответы в основном дают советы «быть последовательными», что означает, что если какая-то часть языка может реально вызвать двойную кавычку, вы должны последовательно использовать эту двойную кавычку.
Джош из Карибу

18
Это также актуально при работе с несколькими языками, где почти все другие языки (Java, C, C ++, ...) используют двойные кавычки для строк и одинарные кавычки для символов. Я предпочитаю использовать одинаковые цитаты по всем направлениям, поэтому придерживайтесь двойных кавычек для JS. При многолетнем сенсорном наборе дополнительная клавиша для сдвига для двойных кавычек совершенно неактуальна, и если ваше кодирование ограничено вашим набором текста, вам нужно попрактиковаться в правильном наборе.
Лоуренс Дол

336

Нет лучшего решения ; Тем не менее, я хотел бы утверждать, что двойные кавычки могут быть более желательными в разы:

  • Новички уже знакомы с двойными кавычками на своем языке. . На английском языке мы должны использовать двойные кавычки, "чтобы идентифицировать отрывок цитируемого текста. Если бы мы использовали одну цитату ', читатель может неверно истолковать ее как сокращение. Другое значение отрывка текста в окружении 'указывает на «разговорный» смысл. Имеет смысл оставаться в соответствии с ранее существовавшими языками, и это может облегчить изучение и интерпретацию кода.
  • Двойные кавычки избавляют от необходимости избегать апострофов (как в сокращениях). Рассмотрим строку: "I'm going to the mall", по сравнению с иным экранированием: 'I\'m going to the mall'.
  • Двойные кавычки означают строку во многих других языках . Когда вы изучаете новый язык, такой как Java или C, всегда используются двойные кавычки. В Ruby, PHP и Perl строки в одинарных кавычках не подразумевают экранирования обратной косой черты, в то время как двойные кавычки поддерживают их.

  • Запись в формате JSON пишется в двойных кавычках.

Тем не менее, как утверждали другие, очень важно оставаться последовательным.


Ваше первое замечание по английскому языку не всегда верно и может меняться в зависимости от соглашения о местности / доме. Печатные материалы обычно используют одиночные кавычки для речи и используют другое форматирование для больших блоков цитируемого текста. Ваше «разговорное» значение не является полезным определением кавычек для акцента. Плюс английские пользователи вообще очень бедны с кавычками и апострофами.
Джон Фергюсон

2
@JohnFerguson, только по этой причине может быть желательно использовать двойные кавычки, чтобы провести это различие (между апострофами и цитируемыми отрывками).
user1429980

Я все о прагматизме. Из-за того, что 1 из 100 строк, которые я печатаю или использую, имеет двойные кавычки, а многие, многие другие имеют апострофы, я использую двойные. В конце концов, однако, вы должны использовать тип цитаты, который 1) уже используется в проекте, если вы новый разработчик проекта, или 2) использовать тот, который, по вашему мнению, имеет больше смысла.
dudewad

Показательный пример - то, что я только что напечатал (есть несколько апострофов, двойных кавычек нет;)
dudewad

FWIW - это цитата из статьи Quora: quora.com/…
theUtherSide

118

Раздел 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 + ', то вы делаете это неправильно.
SgtPooki

1
А как насчет "{\"name\": \"Peter\"}"против '{"name": "Peter"}'? По общему признанию, вы могли бы сказать, что это та же разница, но это, безусловно, повлияет на ваше решение не так, как в примере выше.
Тревор

@MathiasBynens - это интересное наблюдение, которое не было актуальным как минимум год, а может и целых 6 лет.
ArtOfWarfare

4
Нужно использовать U + 2019 для апострофа, а не вертикальную одинарную кавычку
jjg

95

Одинарные кавычки

Я хотел бы, чтобы двойные кавычки были стандартом, потому что они имеют немного больше смысла , но я продолжаю использовать одинарные кавычки, потому что они доминируют на сцене.

Одинарные кавычки:

Нет предпочтений:

Двойные кавычки:


7
Крокфорд теперь предпочитает двойные кавычки.
Адам Кальвет Бол

6
airbnb теперь предпочитает двойные кавычки
Сурадж Джейн

15
@SurajJain Источник? Руководства по стилям Airbnb и Google по- прежнему перечисляются в качестве предпочтительных.
Алек

5
@SurajJain А, это конфиг проверки стиля кода, написанный на JSON, который вообще не допускает одинарные кавычки. Их чтение - хороший способ сравнить выбор, сделанный различными проектами.
Алек

2
Google теперь предпочитает одинарные кавычки
GabrielOshiro

57

Я хотел бы сказать, что разница чисто стилистическая, но у меня действительно есть сомнения. Рассмотрим следующий пример:

/*
   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 (протестировано в IE7 и IE8) это вернет следующее:

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 году.

Кажется, что одинарные кавычки иногда бывают быстрее в Windows Explorer (примерно 1/3 моих тестов показывали более быстрое время отклика), но если Mozilla вообще показывает разницу, он обрабатывает двойные кавычки немного быстрее. Я не обнаружил никакой разницы в Opera.

Редактировать 2014: современные версии Firefox / Spidermonkey больше не делают этого.


25
Если в одном браузере это происходит немного быстрее, а в другом - немного быстрее, то кажется, что единственное руководство, от которого мы можем отказаться, это то, что мы должны делать все, что нам больше нравится, потому что это повредит некоторым пользователи и помогают другим, и количество различий, вероятно, будет незаметным. «Преждевременная оптимизация ...» и все такое.
Эндрю Хеджес

2
Извините, мой комментарий не был более конструктивным. Я только говорю, что то, как браузер выбирает отображение своего внутреннего представления синтаксиса, вероятно, имеет очень мало общего с тем, как он анализируется, и поэтому, вероятно, не является причиной для предпочтения одного типа кавычек над другим. С другой стороны, данные о производительности, сравнивающие время разбора одинарных и двойных кавычек в разных браузерах, были бы более убедительными.
Крис Кало

1
Это потрясающий ответ, отдохнувший от всего остального, который просто щебетает: «Они одинаковые, они одинаковые» ... Вы сказали: «Плюс, в других языках программирования их обычно быстрее использовать, чем удваивать». цитаты " Могу я спросить, на каких языках? Я использовал обычные языки, такие как Java и C #, никогда не видел ни одного, кроме JS, который принимает строковые литералы в одинарных кавычках. Вложения в одинарные кавычки обычно используются только для символьных констант (допускается только один символ).
ADTC

3
AFAIK это было исправлено в Firefox 17, Firefox раньше делал декомпиляцию, .toStringно теперь возвращает оригинальную копию. Современный Firefox не будет иметь этой проблемы.
Бенджамин Грюнбаум

3
Не знаю о разнице в скорости. Но я хотел бы отметить, что «создается впечатление, что по крайней мере один браузер внутренне анализирует JavaScript, как будто все написано с использованием двойных кавычек». ерунда Разбирается так, как будто написано в двойных кавычках. То есть он превратил свое внутреннее представление (которое просто хранит строку, а не кавычки) в читаемую человеком версию, для которой случается использовать один набор кавычек. Во всяком случае, похоже, что это изменилось, согласно комментарию Бенджамина.
subsub

32

Если вы используете встроенный JavaScript (возможно, «плохая» вещь, но избегаете этого обсуждения) , то, как мне кажется, единственные кавычки - ваш единственный вариант для строковых литералов.

например, это работает нормально:

<a onclick="alert('hi');">hi</a>

Но вы не можете заключить "привет" в двойные кавычки, используя любой метод экранирования, который я знаю. Даже то, &quot;что было бы моим лучшим предположением (поскольку вы избегаете кавычек в значении атрибута HTML), не работает для меня в Firefox. \"тоже не сработает, потому что на этом этапе вы используете HTML, а не JavaScript.

Итак, если название игры - последовательность, и вы собираетесь использовать встроенный JavaScript в некоторых частях вашего приложения, я думаю, что одинарные кавычки - победитель. Кто-нибудь, пожалуйста, поправьте меня, если я ошибаюсь.


8
Договорились о том, что это, возможно, плохо, однако, если это необходимо сделать, я уверен, что можно использовать кодировку в стиле URL, например, <a onclick="alert(%22hi%22);">hi</a>- из памяти это работает, хотя вместо этого это могло быть в атрибуте href<a href="javascript:alert(%22hi%22);">hi</a>
Graza

2
@PhiLho, вы правы насчет этого ... Я предполагал, что люди писали HTML-атрибуты с традиционными двойными кавычками и не собирались ни (1) массово конвертировать все в одинарные кавычки, либо (2) смешивать и сопоставлять одинарные и двойные кавычки. Но да, вы правы, это законно
Том Лианца

4
@Tom Lianza, конечно alert(&quot;hi&quot;), не является правильным JavaScript. Но значения атрибутов закодированы. w3.org/TR/html4/intro/sgmltut.html#didx-attribute
Роберт,

4
Договорились с @Robert здесь. &quot;это правильный способ избежать двойной кавычки внутри атрибута HTML. Он отлично работает в Firefox. @Denilson, XML (и, следовательно, XHTML) допускает как одинарные, так и двойные кавычки. См. AttValueЛитерал в спецификации XML на w3.org/TR/REC-xml/#d0e888 .
Крис Кало

1
@Pacener: Потому что это не так. В HTML существует соглашение помещать атрибуты между двойными кавычками.
Конрад Боровски

30

Технически нет никакой разницы, это только вопрос стиля и соглашения.

Дуглас Крокфорд рекомендует использовать одинарные кавычки для внутренних строк и двойные кавычки для внешних (под внешними мы подразумеваем те, которые должны отображаться пользователю приложения, такие как сообщения или оповещения).

Я лично следую за этим.

ОБНОВЛЕНИЕ: кажется, что мистер Крокфорд передумал и теперь рекомендует использовать двойные кавычки :)


13
Дуглас Крокфорд против JQuery. Выбрать свой яд.
Эрик

В чем причина Крокфорда?
BadHorsie

1
Это соглашение, которому я следую. Это больше личных предпочтений. Мне нравится использовать строки в одинарных кавычках для внутренних вещей, таких как селекторы jQuery и / или такие вещи, как getElementById ('id'); мне просто нравится, как это выглядит в одинарных кавычках. Но переключитесь на двойные кавычки для внешнего текста, поскольку он часто может содержать внутренние кавычки в тексте. Кроме того, он позволяет легко находить и различать внешние и внутренние строки, если вы пытаетесь найти ошибку в одной или другой.
adimauro

3
По состоянию на апрель 2016 года Дуглас Крокфорд теперь рекомендует использовать только двойные кавычки, учитывая, что на практике многие разработчики сочли внутреннюю и внешнюю дихотомию трудной для использования.
Thunderforge

27

Строго говоря, нет никакой разницы в значении; так что выбор сводится к удобству.

Вот несколько факторов, которые могут повлиять на ваш выбор:

  • Домашний стиль: некоторые группы разработчиков уже используют одно соглашение или другое.
  • Требования на стороне клиента: Будете ли вы использовать кавычки в строках? (См. Ответ Ади).
  • Язык на стороне сервера: люди VB.Net могут выбрать использование одинарных кавычек для java-скрипта, чтобы скрипты могли быть построены на стороне сервера (VB.Net использует двойные кавычки для строк, поэтому строки java-скрипта легко различить если они используют одинарные кавычки).
  • Код библиотеки: если вы используете библиотеку, которая использует определенный стиль, вы можете рассмотреть возможность использования того же стиля самостоятельно.
  • Личные предпочтения: вы можете подумать, что тот или иной стиль выглядит лучше.

Не правда, 'находится 00100111в двоичной системе , в то время как "это 00100010в двоичной системе . Таким образом, двойные кавычки требуют вдвое меньше энергии для хранения, чем одинарные. Это разница прямо там.

19

Давайте посмотрим, что делает ссылка.

Внутри jquery.js каждая строка заключена в двойные кавычки.

Итак, теперь я буду использовать строки в двойных кавычках. (Я использовал сингл!)


11
Почему за это проголосовали. Это вопрос стиля, и лучший стиль - быть последовательным и следовать тем, кто был до вас.
Эрик

2
+1 Документация по jQuery API тоже. Это была единственная причина, по которой я согласился на двойные кавычки. Лично я думаю, что ответы, что «все сводится к личным предпочтениям», немного ошибочны - лучше всего найти широко используемое соглашение и придерживаться его. И поскольку я могу захотеть копировать и вставлять примеры из jQuery (прямо или косвенно), я не хочу каждый раз заменять кавычки.
Стив Чэмберс

2
Возможно, jQuery не смог последовать за людьми до них (или действительно не заботился, как большинство других экспертов). ;)
Джеймс Уилкинс

14

Просто сохраняйте последовательность в том, что вы используете. Но не подводите свой уровень комфорта.

"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

ES6 обновление

Использование буквального синтаксиса шаблона .

`Be "my" guest. You're in complete freedom.`; // most comfort :D

13

Это в основном вопрос стиля и предпочтений. В других ответах есть несколько довольно интересных и полезных технических исследований, так что, пожалуй, единственное, что я могу добавить, это дать немного мирских советов.

  • Если вы программируете в компании или команде, то , вероятно, стоит следовать «домашнему стилю».

  • Если вы в одиночку хакерство несколько побочных проектов, а затем посмотреть на несколько видных лидеров в обществе. Например, допустим, вы попали в Node.js. Взгляните на основные модули, например underscore.js или express, и посмотрите, какое соглашение они используют, и подумайте о том, чтобы им следовать.

  • Если оба соглашения используются в равной степени, тогда придерживайтесь ваших личных
    предпочтений.

  • Если у вас нет личных предпочтений, то монетка.

  • Если у вас нет монеты, то пиво на мне;)


13

Я надеюсь, что не добавляю что-то очевидное, но я боролся с Django и Ajax и JSON на этом.

Предполагая, что в вашем HTML-коде вы используете двойные кавычки, как обычно должно быть, я настоятельно рекомендую использовать одинарные кавычки для остальных в JavaScript.

Так что я согласен с @ady, но с некоторой осторожностью.

Суть в том, что в JavaScript, вероятно, это не имеет значения, но как только вы внедрите его в HTML или что-то подобное, у вас начнутся проблемы. Вы должны знать, что на самом деле ускользает, читает, передает вашу строку.

Мой простой случай был:

tbox.innerHTML = tbox.innerHTML + '<div class="thisbox_des" style="width:210px;" onmouseout="clear()"><a href="https://stackoverflow.com/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>'

Вы можете найти \ 'в третьем поле шоу.

Двойная кавычка не сработала!

Понятно почему, но также понятно, почему мы должны придерживаться одинарных кавычек ... .. Я думаю ...

Этот случай представляет собой очень простое встраивание HTML, ошибка была сгенерирована простым копированием / вставкой из кода JavaScript с двойными кавычками.

Итак, чтобы ответить на вопрос:

Попробуйте использовать одинарные кавычки в HTML. Это может спасти пару проблем отладки ...


1
Я столкнулся с подобной проблемой с интерполяцией строк ES6 (обратные метки). Моя система сборки скомпилировала его в строку в двойных кавычках, которая сломала заголовок Auth, который работал с одинарными кавычками!
Джей

12

Не уверен, что это актуально в современном мире, но двойные кавычки использовались для контента, который должен обрабатываться управляющими символами, и одинарные кавычки для строк, которые этого не делали.

Компилятор будет запускать манипуляции со строками в строке в двойных кавычках, оставляя строку в одинарных кавычках буквально нетронутой. Раньше это приводило к тому, что «хорошие» разработчики выбирали использование одинарных кавычек для строк, которые не содержали управляющих символов, таких как \nили \0(не обработанных в одинарных кавычках), и двойных кавычек, когда им требовалось проанализировать строку (за небольшую плату в циклах процессора для обработка строки).


14
Дело не в том, что раньше все делалось одним способом, а теперь - другим. Различные языки обрабатывают кавычки по-разному, а некоторые работают так, как вы описываете. Но это вопрос JavaScript . Одиночные и двойные кавычки обрабатываются одинаково в JavaScript (за исключением того, что в строке можно использовать кавычки другого типа без экранирования). Речь не идет о двойных кавычках, допускающих управляющие символы или интерполяцию строк. JavaScript не работает так. Управляющие символы и escape-последовательности работают в зависимости от того, какой тип цитаты вы используете.
Майкл Гири

Как бывший программист Perl, я продолжаю думать об этом, хотя знаю, что это не имеет отношения к JS.
zkent

12

Если вы используете jshint , это вызовет ошибку, если вы используете двойные кавычки.

Я использовал его через Yeoman леса AngularJS, но, возможно, есть какой-то способ настроить это.

Кстати, когда вы обрабатываете HTML в JavaScript, проще использовать одинарные кавычки:

var foo = '<div class="cool-stuff">Cool content</div>';

И, по крайней мере, JSON использует двойные кавычки для представления строк.

Там нет тривиального способа ответить на ваш вопрос


Изменилась ли реализация jshint? так как демонстрационный сайт, кажется, принимает либо без выдачи каких-либо предупреждений / ошибок, и я не могу найти какие-либо варианты, чтобы ограничить использование jshint либо. Возможно, этот ответ устарел или неточен?
Леа Хейс

если jshint вызывает ошибку для строки в двойных кавычках, она серьезно нарушается. Стандарт JavaScript определяет, что является правильным, а не какой-то сломанный линтер.
Меки

10

Говоря о производительности, кавычки никогда не станут вашим узким местом, однако производительность в обоих случаях одинакова.

Говоря о скорости кодирования, если вы используете 'для разделения строки, вам нужно будет избегать "кавычек. Вам, скорее всего, придется использовать "внутри строки, например:

//JSON Objects:
var jsonObject = '{"foo":"bar"}';
//HTML attributes:
document.getElementById("foobar").innerHTML = '<input type="text">';

Затем я предпочитаю использовать 'для разделения строки, поэтому мне нужно экранировать меньше символов.


10

Одна (глупая) причина использовать одинарные кавычки состоит в том, что они не требуют от вас нажатия клавиши Shift для их ввода, тогда как двойные кавычки делают. (Я предполагаю, что средняя строка не требует экранирования, что является разумным предположением.) Теперь давайте предположим, что каждый день я кодирую 200 строк кода. Может быть, в этих 200 строках у меня 30 цитат. Возможно, ввод двойной кавычки занимает на 0,1 секунды больше времени, чем ввод одинарной кавычки (потому что я должен нажать клавишу Shift). Затем в любой день я трачу 3 секунды. Если я буду кодировать таким образом 200 дней в году в течение 40 лет, то я потрачу впустую 6,7 часа своей жизни. Пища для размышлений.


1
Я предполагаю, что вы имеете в виду только английскую раскладку клавиатуры ... У меня есть немецкая, мне нужно нажать shift для обоих. Во всяком случае, я не понимаю, почему нажатие клавиши Shift добавляет время к процессу. Я нажимаю клавишу shift левой рукой и нажимаю клавишу кавычки правой. Это происходит одновременно, для меня нет никакой разницы.
Codewandler

1
@codewandler Все еще есть необходимость нажимать клавишу Shift, даже если вы можете нажать ее параллельно клавише ". Это заставляет вас отодвинуть палец от положения по умолчанию. Например, предположим, что вы печатаете: var description = "This is a \"quick\" test";on английская клавиатура. Для английской клавиатуры ваш мизинец должен двигаться от левой клавиши Shift к клавише Q в верхнем ряду, а не от клавиши A к клавише Q. Другими словами, он должен проходить вдвое больше расстояния Я не уверен, где находятся клавиши на немецкой клавиатуре, но я уверен, что есть аналогичный пример
Джон Курлак

2
@codewandler Кроме того, необходимость набирать shift, даже если я могу делать это параллельно, не позволяет левому мизинцу подготовиться к вводу следующего символа после «во что бы вы ни печатали»
Джон Курлак,

1
Идея «тратить время» немного глупа, но идея о менее эргономическом напряжении (особенно в эпоху синдрома карпелевого туннеля и т. Д.) Делает это хорошим приобретением, особенно в тех случаях, когда в противном случае это не имеет значения. Учитывая более 1000 строк кода в день, это может сэкономить сотни ежедневных изгибов мизинца.
Бежор

9

Изучение плюсов и минусов

В пользу одинарных кавычек

  • Менее визуальный беспорядок.
  • Генерация HTML: атрибуты HTML обычно разделяются двойными кавычками.

elem.innerHTML = '<a href="' + url + '">Hello</a>';
Однако одинарные кавычки в HTML так же легальны.

elem.innerHTML = "<a href='" + url + "'>Hello</a>";

Кроме того, встроенный HTML обычно является анти-шаблоном. Предпочитаю шаблоны.

  • Генерация JSON: в JSON допускаются только двойные кавычки.

myJson = '{ "hello world": true }';

Опять же, вам не нужно создавать JSON таким образом. JSON.stringify () достаточно часто. Если нет, используйте шаблоны.

В пользу двойных кавычек

  • Удваивать легче, если у вас нет цветовой кодировки. Как в журнале консоли или какой-то настройке вида источника.
  • Сходство с другими языками: в программировании оболочки (Bash и т. Д.) Строковые литералы в одинарных кавычках существуют, но экранирование не интерпретируется внутри них. C и Java используют двойные кавычки для строк и одинарные кавычки для символов.
  • Если вы хотите, чтобы код был действительным JSON, вам нужно использовать двойные кавычки.

В пользу обоих

Нет никакой разницы между этими двумя в JavaScript. Поэтому вы можете использовать все, что удобно в данный момент. Например, следующие строковые литералы производят одну и ту же строку:

    "He said: \"Let's go!\""
    'He said: "Let\'s go!"'
    "He said: \"Let\'s go!\""
    'He said: \"Let\'s go!\"'

Одинарные кавычки для внутренних строк и двойные для внешних. Это позволяет отличать внутренние константы от строк, которые должны отображаться пользователю (или записываться на диск и т. Д.). Очевидно, вам следует избегать добавления последних в ваш код, но это не всегда можно сделать.


8

Еще одна вещь, которую вы могли бы рассмотреть в качестве причины перехода от двойных к одиночным кавычкам, - это рост популярности серверных сценариев. При использовании PHP вы можете передавать переменные и анализировать функции JavaScript, используя строки и переменные в PHP.

Если вы пишете строку и используете двойные кавычки для своего PHP, вам не нужно будет избегать ни одной из одинарных кавычек, и PHP автоматически получит значение переменных для вас.

Пример: мне нужно запустить функцию javascript, используя переменную с моего сервера.

public static function redirectPage( $pageLocation )
{
    echo "<script type='text/javascript'>window.location = '$pageLocation';</script>";
}

Это избавляет меня от хлопот, связанных с объединением строк, и я могу эффективно вызывать JavaScript из PHP. Это только один пример, но это может быть одной из нескольких причин, почему программисты по умолчанию используют одинарные кавычки в javascript.

Цитата из документов PHP : «Самая важная особенность строк в двойных кавычках заключается в том, что имена переменных будут расширены. Подробности смотрите в разборе строк».


+1, я делаю это в своем проекте MVC.Net, чтобы двойные кавычки из C # не мешали одинарным кавычкам из javascript, и наоборот.
DCShannon

3
Я думаю, что если вы пишете JavaScript на свою страницу из метода класса PHP, у вас есть большие проблемы.
BadHorsie

6

Есть люди, которые утверждают, что видят различия в производительности: старая ветка списка рассылки . Но я не смог найти ни одного из них, чтобы подтвердить.

Главное - посмотреть, какие кавычки (двойные или одинарные) вы используете внутри своей строки. Это помогает сохранить количество побегов на низком уровне. Например, когда вы работаете с html внутри ваших строк, проще использовать одинарные кавычки, чтобы вам не пришлось экранировать все двойные кавычки вокруг атрибутов.


Хотя атрибуты также могут быть
заключены в

Ваше право, я думал, что xml и xhtml предписывают двойные кавычки, окружающие атрибуты, но одинарные кавычки разрешены.
Михил Оверим

6

Я бы использовал двойные кавычки, когда нельзя использовать одинарные кавычки, и наоборот:

"'" + singleQuotedValue + "'"
'"' + doubleQuotedValue + '"'

Вместо:

'\'' + singleQuotedValue + '\''
"\"" + doubleQuotedValue + "\""

Как насчет строки, содержащей как одинарные, так и двойные кавычки, такие как O'rea? Lly
sudhAnsu63

6

В JavaScript нет разницы между одинарными и двойными кавычками.

Спецификация важна:

Возможно, существуют различия в производительности, но они абсолютно минимальны и могут меняться каждый день в зависимости от реализации браузера. Дальнейшее обсуждение бесполезно, если ваше JavaScript-приложение не имеет сотни тысяч.

Это как ориентир, если

a=b;

быстрее чем

a = b;

(лишние пробелы)

сегодня в конкретном браузере и платформе и т. д.


2
без пробелов быстрее. меньше символов для разбора в строке. : p
pilavdzice

6

При использовании CoffeeScript я использую двойные кавычки. Я согласен, что вы должны выбрать любой из них и придерживаться его. CoffeeScript дает вам интерполяцию при использовании двойных кавычек.

"This is my #{name}"

ES6 использует обратные галочки (`) для строк шаблона. Что, вероятно, имеет вескую причину, но при кодировании может быть затруднительно изменить символ строковых литералов с кавычек или двойных кавычек на обратные тики, чтобы получить возможность интерполяции. CoffeeScript может быть не идеальным, но использование везде одинаковых символов строковых литералов (двойные кавычки) и всегда возможность интерполировать - хорошая функция.

`This is my ${name}`

Для меня обратный тик является явным победителем в этом конкурсе, (почти) нет присутствия внутри общих текстовых строк, плюс вар интерполяция
Симона Погги

5

Если вы перепрыгиваете вперед между JavaScript и C #, лучше потренировать пальцы для общего соглашения, заключающегося в двойных кавычках.


5

Я выполнял следующие около 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));

31
Иными словами, вы обнаружили, что более поздний код работает быстрее всего. Это проблема при выполнении микро-тестов. Вы должны учитывать движок JS, оптимизирующий код во время его работы. (Вы увидите тот же эффект при тестировании Java из-за того, как работает JIT.)
Дэвид Филлипс

4
первая новая дата медленно, добавить var dummy_date = new Date()в начало
Лаури

1
Уровень микрооптимизации здесь настолько глуп, что вы также можете утверждать, что одинарные кавычки быстрее набираются, что приводит к ускорению разработки.
Beejor

4

Строго нет никакой разницы, так что это в основном вопрос вкуса и того, что находится в строке (или, если сам код JS находится в строке), чтобы сохранить число выходов низким.

Легенда о разнице в скорости может происходить из мира PHP, где две кавычки ведут себя по-разному.


И Руби, я могу добавить. Python ведет себя так же, как JavaScript: разницы между одинарными / двойными кавычками нет.
Дамир Зекич

4

Прочитав все ответы, в которых говорится, что это может быть быстрее или может иметь преимущества, я бы сказал, что двойные кавычки лучше, а может быть, и быстрее, потому что компилятор закрытия Google преобразует одинарные кавычки в двойные.


Вы знаете, почему это происходит?
ma11hew28

Я не знаю. Может быть, это соглашение о кодировании и ничего особенного.
Мохсен

4

Теперь, когда наступил 2020 год, мы должны рассмотреть третий вариант для Javascript: единый обратный удар для всего.

Это может использоваться везде вместо одинарных или двойных кавычек.

Это позволяет вам делать все!

  1. Вставьте в него одинарные кавычки: «Это здорово!»
  2. Вставьте в него двойные кавычки: «Это действительно здорово!»
  3. Используйте строковую интерполяцию: `Это" $ {лучше} ", чем здорово!`
  4. Это позволяет несколько строк: `

    Эта

    делает

    Javascript

    Лучше!

    `

Это также не приводит к снижению производительности при замене двух других: https://medium.com/javascript-in-plain-english/are-backticks-slower-than-other-strings-in-javascript-ce4abf9b9fa


3

Если ваш источник JS:

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>

JS позволяет такие массивы:

var arr=['this','that'];

Но если вы приведете его в соответствие, это будет по совместимой причине:

JSON=["this","that"]

Я уверен, что это займет некоторое время.


3

Просто добавьте мои 2 цента: Работая с JS и PHP несколько лет назад, я привык использовать одинарные кавычки, поэтому я могу набирать escape-символ ('\'), не прибегая к его экранированию. Я обычно использовал его при наборе необработанных строк с путями к файлам и т. Д. ( Http://en.wikipedia.org/wiki/String_literal#Raw_strings )

Как бы то ни было, мое соглашение в конечном итоге стало использование одинарных кавычек в необработанных строках идентификатора, таких как if (typeof s == 'string') ...(в которых escape-символы никогда не будут использоваться - никогда), и двойных кавычек для текстов , таких как «Эй, что случилось?». Я также использую одинарные кавычки в комментариях как типографское соглашение, чтобы показать имена идентификаторов. Это всего лишь практическое правило, и я прекращаю работу только тогда, когда это необходимо, например, при вводе строк HTML '<a href="#"> like so <a>'(хотя здесь вы также можете изменить кавычки). Мне также известно, что в случае JSON для имен используются двойные кавычки, но, помимо этого, лично я предпочитаю одинарные кавычки, когда экранирование никогда не требуется для текста между кавычками - как document.createElement('div').

В итоге, и, как некоторые упоминали / ссылались на него, выберите соглашение, придерживайтесь его и отклоняйте его только при необходимости.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.