¿Cuándo usar comillas dobles o simples en JavaScript?

1969

console.log("double"); vs console.log('single');

Veo más y más bibliotecas de JavaScript por ahí usando comillas simples al manejar cadenas. ¿Cuáles son las razones para usar una sobre la otra? Pensé que son bastante intercambiables.

aemkei
fuente
125
¿Cuál es más fácil de leer? alerta ("Es hora del juego"); o alerta ('Es hora del juego');
Ryan Miller
591
¿Qué tal este Ryan? alert("It's \"game\" time.");o alert('It\'s "game" time.');?
Francisc
37
Si siempre se usaron comillas simples y ocasionalmente comillas dobles donde el literal contiene comillas simples, entonces tendremos que escribir muchos menos botones de mayúsculas y nuestro dedo meñique izquierdo nos dará bendiciones. Pero sí, como dijo @arne, para JSON se debe utilizar la comilla doble.
IsmailS
99
Las comillas simples son más fáciles de hacer cuando estás en un teclado europeo (la comilla doble es Shift + 2, que no es tan dulce como tocar una sola tecla convenientemente con tu dedo meñique derecho).
Arne
38
@Arne No existe el "teclado europeo". Por ejemplo, el teclado alemán requiere desplazamiento para ambos tipos de comillas. (Pero las comillas simples son más fáciles.)
ANeves

Respuestas:

1223

La razón más probable para el uso de single vs double en diferentes bibliotecas es la preferencia del programador y / o la consistencia API. Además de ser consistente, use el que mejor se adapte a la cuerda.

Usando el otro tipo de cita como literal:

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

Esto puede complicarse:

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

Otra opción, nueva en ES6, son los literales de plantilla que usan el back-tickcarácter:

alert(`Use "double" and 'single' quotes in the same string`);
alert(`Escape the \` back-tick character and the \${ dollar-brace sequence in a string`);

Los literales de plantilla ofrecen una sintaxis limpia para: interpolación variable, cadenas de varias líneas y más.

Tenga en cuenta que JSON se especifica formalmente para usar comillas dobles, lo que puede valer la pena considerar dependiendo de los requisitos del sistema.

Beau Smith
fuente
85
Un punto importante a tener en cuenta con todas las convenciones de código: defínalo una vez y cúmplalo. IOW, no use comillas dobles en algún lugar y comillas simples en otro lugar.
Cerebrus
170
@Cerebrus: creo que la flexibilidad está bien con este. Claro que elija un estilo preferido, pero si necesita separarse del estilo para guardar el escape de muchas citas en una cadena. Estaría bien con eso.
Martin Clarke
55
No creo que haya ninguna razón para ser coherente al respecto. No hay ninguna ventaja a cualquiera de los dos, y no creo que la legibilidad es realmente afectada si se utiliza o no "en un lugar y" en otro.
cdmckay
2
@Olly Hicks, prueba interesante !! Las comillas simples son en realidad varias veces más rápidas que las comillas dobles aquí en Chrome 13 (OSX). Interesante ...
Ricket
12
Un poco fuera de tema, pero si la gente usara la tipografía correcta, muchas de estas discusiones sobre escapar serían obsoletas: alert('It’s “game” time')vs. alert("It’s “game” time")- no importa. Sólo se necesitaría para escapar de los casos (raros) donde el signo primer sencillo o doble ', "es el más adecuado.
jotaen
617

Si se trata de JSON, debe tenerse en cuenta que, estrictamente hablando, las cadenas JSON deben estar entre comillas dobles. Claro, muchas bibliotecas también admiten comillas simples, pero tuve grandes problemas en uno de mis proyectos antes de darme cuenta de que las comillas simples no están de acuerdo con los estándares JSON.

Arne
fuente
55
Esto es muy relevante cuando se trabaja con jQuery.ajax llamando a un servicio ASP.NET (servicio web, método de página o MVC).
Schmuli
100
Los nombres de propiedad dentro de las cadenas JSON deben ser entre comillas dobles, pero una cadena JSON en su conjunto puede ser entre comillas simples: var jsonString = '{"key1":"value1"}';(No es que recomiendo construir manualmente JSON.)
nnnnnn
51
No debe escribir JSON a mano si puede .stringify()hacerlo.
Camilo Martin
23
Este es el mejor argumento para usar siempre comillas dobles. JSON debe tener comillas dobles. Las otras respuestas en su mayoría dan consejos para "ser coherentes", lo que significa que si alguna parte del lenguaje puede forzar de manera realista una comilla doble, debe usarla constantemente.
Josh de Qaribou
18
Esto también es relevante cuando se trabaja con varios idiomas donde casi todos los demás idiomas (Java, C, C ++, ...) usan comillas dobles para cadenas y comillas simples para caracteres. Prefiero usar la misma cita en todos los ámbitos y, por lo tanto, seguir con comillas dobles para JS. Con años de escritura táctil, la tecla adicional para cambiar para comillas dobles es completamente irrelevante, y si su codificación está limitada por su escritura, entonces necesita practicar la escritura correctamente.
Lawrence Dol
336

No hay una mejor solución ; Sin embargo, me gustaría argumentar que las comillas dobles pueden ser más deseables a veces:

  • Los recién llegados ya estarán familiarizados con las comillas dobles de su idioma . En inglés, debemos usar comillas dobles "para identificar un pasaje del texto citado. Si tuviéramos que usar una cita simple ', el lector podría malinterpretarla como una contracción. El otro significado de un pasaje de texto rodeado por el 'indica el significado 'coloquial'. Tiene sentido ser coherente con los lenguajes preexistentes, y esto puede facilitar el aprendizaje y la interpretación del código.
  • Las comillas dobles eliminan la necesidad de escapar de los apóstrofes (como en las contracciones). Considere la cadena: "I'm going to the mall", frente a la versión escapado de otro modo: 'I\'m going to the mall'.
  • Las comillas dobles significan una cadena en muchos otros idiomas . Cuando aprende un nuevo lenguaje como Java o C, siempre se utilizan comillas dobles. En Ruby, PHP y Perl, las cadenas entre comillas simples no implican escapes de barra invertida, mientras que las comillas dobles las admiten.

  • La notación JSON se escribe con comillas dobles.

Sin embargo, como han dicho otros, es muy importante permanecer consistente.

usuario149999
fuente
Su primer punto sobre el idioma inglés no siempre es cierto y puede cambiar dependiendo de la convención de la localidad / casa. Los materiales impresos generalmente usan comillas simples para el discurso y usan otro formato para grandes bloques de texto citado. Su significado 'coloquial' no es una definición útil de citas para enfatizar. Además, los usuarios de inglés en general son muy pobres con comillas y apóstrofes.
John Ferguson
2
@JohnFerguson, solo por esa razón, puede ser conveniente usar comillas dobles para hacer esa diferenciación (entre apóstrofes y pasajes citados).
user1429980
Soy todo sobre el pragmatismo. Debido al hecho de que 1 de cada 100 cadenas que escribo o utilizo tiene comillas dobles, y muchas, muchas más tienen apóstrofes, utilizo dobles. Al final del día, sin embargo, debe usar el tipo de presupuesto que es 1) que ya está en uso en el proyecto si es un desarrollador nuevo para el proyecto, o 2) use el que cree que tiene más sentido.
dudewad
Caso en el point-- lo que acaba de escribir (hay múltiples apóstrofes, sin comillas dobles;)
dudewad
FWIW - esta es una cita de un artículo de Quora: quora.com/…
theUtherSide
118

La sección 7.8.4 de la especificación describe la notación de cadena literal. La única diferencia es que DoubleStringCharacter es "SourceCharacter pero no entre comillas dobles" y SingleStringCharacter es "SourceCharacter pero no entre comillas simples". Entonces, la única diferencia se puede demostrar así:

'A string that\'s single quoted'

"A string that's double quoted"

Por lo tanto, depende de la cantidad de presupuesto que quiera hacer. Obviamente, lo mismo se aplica a las comillas dobles en cadenas de comillas dobles.

Gareth
fuente
@Gareth: Sin embargo, no estaba hablando de especificaciones, estaba hablando de un posible impacto en el rendimiento. stackoverflow.com/questions/242813/…
Mathias Bynens
si está poniendo suficientes apóstrofes en su código para compensar cuántas veces necesita presionar shift + ', entonces lo está haciendo mal.
SgtPooki
1
¿Qué hay de "{\"name\": \"Peter\"}"vs '{"name": "Peter"}'? Es cierto que podría decir que esta es la misma diferencia, pero ciertamente afectaría su decisión de una manera diferente al ejemplo anterior.
Trevor
@MathiasBynens: esa es una observación interesante que no ha sido relevante durante al menos un año, y tal vez hasta 6 años.
ArtOfWarfare
44
Uno debería usar U + 2019 para un apóstrofe, no una comilla simple vertical
jjg
95

Comillas simples

Desearía que las comillas dobles fueran el estándar, porque tienen un poco más de sentido , pero sigo usando comillas simples porque dominan la escena.

Comillas simples:

Sin preferencias:

Doble comillas:

Alec Mev
fuente
77
Crockford ahora prefiere las comillas dobles.
Adam Calvet Bohl
66
airbnb ahora prefiere comillas dobles
Suraj Jain
15
@SurajJain Source? Las guías de estilo de Airbnb y Google todavía enumeran solo como preferido.
Alec Mev
55
@SurajJain Ah, estas son configuraciones de comprobador de estilo de código, escritas en JSON, que no permiten comillas simples. Leerlos es una buena manera de comparar las elecciones realizadas por diferentes proyectos.
Alec Mev
2
Google ahora prefiere comillas simples
GabrielOshiro
57

Me gustaría decir que la diferencia es puramente estilística, pero realmente tengo mis dudas. Considere el siguiente ejemplo:

/*
   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);

En Safari, Chrome, Opera e Internet Explorer (probado en IE7 e IE8), esto devolverá lo siguiente:

function () {
 return this.replace(/^\s+|\s+$/g, '');
}
function trim(str) {
 return str.replace(/^\s+|\s+$/g, '');
}

Sin embargo, Firefox producirá un resultado ligeramente diferente:

function () {
    return this.replace(/^\s+|\s+$/g, "");
}
function trim(str) {
    return str.replace(/^\s+|\s+$/g, "");
}

Las comillas simples han sido reemplazadas por comillas dobles. (Observe también cómo se reemplazó el espacio de sangría por cuatro espacios). Esto da la impresión de que al menos un navegador analiza JavaScript internamente como si todo se hubiera escrito entre comillas dobles. Uno podría pensar, Firefox tarda menos tiempo en analizar JavaScript si todo ya está escrito de acuerdo con este 'estándar'.

Lo cual, por cierto, me hace un panda muy triste, ya que creo que las comillas simples se ven mucho mejor en el código. Además, en otros lenguajes de programación, generalmente son más rápidos de usar que las comillas dobles, por lo que solo tendría sentido si lo mismo se aplica a JavaScript.

Conclusión: creo que debemos investigar más sobre esto.

Editar: Esto podría explicar los resultados de las pruebas de Peter-Paul Koch de 2003.

Parece que las comillas simples a veces son más rápidas en Windows Explorer (aproximadamente 1/3 de mis pruebas mostraron un tiempo de respuesta más rápido), pero si Mozilla muestra alguna diferencia, maneja las comillas dobles un poco más rápido. No encontré ninguna diferencia en absoluto en Opera.

Edición 2014: las versiones modernas de Firefox / Spidermonkey ya no hacen esto.

rev. Mathias Bynens
fuente
25
Si es un poco más rápido en un navegador hacerlo de una manera y un poco más rápido en otro para hacerlo de otra manera, parece que la única guía que podemos sacar de eso es que deberíamos hacer lo que más nos guste porque dañará a algunos usuarios y ayudar a otros, y la cantidad de diferencia es probable que sea imperceptible. "Optimización prematura ..." y todo eso.
Andrew Hedges
2
Lo siento, mi comentario no fue más constructivo. Solo digo que la forma en que el navegador elige mostrar su representación interna de la sintaxis probablemente tiene muy poco que ver con cómo se analiza y, por lo tanto, probablemente no sea una razón para preferir un tipo de comillas sobre el otro. Por otro lado, los datos de rendimiento que comparan tiempos de análisis para comillas simples y dobles en navegadores serían más convincentes.
Chris Calo
1
Esta es una respuesta increíble, un descanso del resto que solo dice 'Son lo mismo, son lo mismo' ... Usted dijo "Además, en otros lenguajes de programación, generalmente son más rápidos de usar que el doble comillas " , ¿puedo preguntar qué idiomas? He usado langs regulares como Java y C #, nunca he visto uno que no sea JS que acepte literales de cadena entre comillas simples. Los recintos de comillas simples generalmente se usan solo para constantes de caracteres (solo se permite un carácter).
ADTC
3
AFAIK esto se solucionó en Firefox 17, Firefox solía descompilar cuando lo hacía, .toStringpero ahora devuelve la copia original. Firefox moderno no tendrá este problema.
Benjamin Gruenbaum
3
No sé sobre las diferencias de velocidad. Pero me gustaría señalar que "esto da la impresión de que al menos un navegador analiza JavaScript internamente como si todo estuviera escrito entre comillas dobles". Es una tontería. Se analizó como si estuviera escrito con comillas dobles. Es decir, convirtió su representación interna (que solo almacena la cadena, no las comillas) en una versión legible para humanos, para lo cual utiliza un conjunto de comillas. De todos modos, esto parece haber cambiado, según el comentario de Benjamin.
subsub
32

Si está haciendo JavaScript en línea (posiblemente algo "malo", pero evitando esa discusión) solo comillas son su única opción para los literales de cadena, creo.

Por ejemplo, esto funciona bien:

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

Pero no puede incluir el "hola" entre comillas dobles, a través de cualquier método de escape que conozca. Incluso &quot;lo que habría sido mi mejor suposición (ya que estás escapando de las comillas en un valor de atributo de HTML) no funciona para mí en Firefox. \"tampoco funcionará porque en este punto estás escapando por HTML, no por JavaScript.

Entonces, si el nombre del juego es coherente, y vas a hacer un JavaScript en línea en partes de tu aplicación, creo que las comillas simples son las ganadoras. Sin embargo, que alguien me corrija si me equivoco.

Tom Lianza
fuente
8
Estoy de acuerdo en que podría decirse que es algo malo, sin embargo, si debe hacerse, estoy bastante seguro de que la codificación de estilo URL se puede usar, por ejemplo <a onclick="alert(%22hi%22);">hi</a>, desde la memoria esto funciona, aunque puede haber estado en el atributo href en su lugar<a href="javascript:alert(%22hi%22);">hi</a>
Graza
2
@PhiLho tienes razón sobre eso ... Estaba suponiendo que la gente estaba escribiendo atributos HTML con comillas dobles, y no iban a (1) convertir todo al por mayor a comillas simples, o (2) mezclar y combinar atributos con comillas simples y dobles. Pero sí, tienes razón, es legal
Tom Lianza
44
@ Tom Lianza, seguramente alert(&quot;hi&quot;)no es válido JavaScript. Pero los valores de los atributos están codificados. w3.org/TR/html4/intro/sgmltut.html#didx-attribute
Robert
44
De acuerdo con @Robert aquí. &quot;es la forma correcta de escapar de una comilla doble dentro de un atributo HTML. Funciona bien en Firefox. @Denilson, XML (y por lo tanto XHTML) permite comillas simples y dobles. Vea el AttValueliteral en la especificación XML en w3.org/TR/REC-xml/#d0e888 .
Chris Calo
1
@Pacener: Porque no está mal. Hay una convención en HTML para poner atributos entre comillas dobles.
Konrad Borowski
30

Técnicamente no hay diferencia, solo es cuestión de estilo y convención.

Douglas Crockford recomienda el uso de comillas simples para cadenas internas y comillas dobles para externas (por externo nos referimos a las que se mostrarán al usuario de la aplicación, como mensajes o alertas).

Yo personalmente sigo eso.

ACTUALIZACIÓN: Parece que el Sr. Crockford cambió de opinión y ahora recomienda usar comillas dobles en todo :)

Mariusz Nowak
fuente
13
Douglas Crockford vs JQuery. Elige tu veneno.
Eric
¿Cuál es el razonamiento de Crockford para esto?
BadHorsie
1
Esta es la convención que sigo. Es más preferencia personal. Me gusta usar cadenas con comillas simples para cosas internas como selectores jQuery y / o cosas como getElementById ('id') ;, simplemente me gusta la forma en que se ve con comillas simples. Pero, cambie a comillas dobles para texto externo, ya que a menudo puede contener comillas internas en el texto. Además, hace que sea fácil detectar y diferenciar entre cadenas externas frente a internas si está tratando de encontrar un error en una u otra.
adimauro
3
A partir de abril de 2016, Douglas Crockford ahora recomienda usar solo comillas dobles, dado que en la práctica, muchos desarrolladores encontraron la dicotomía interna versus externa difícil de usar.
Thunderforge
27

Estrictamente hablando, no hay diferencia en el significado; así que la elección se reduce a la conveniencia.

Aquí hay varios factores que podrían influir en su elección:

  • Estilo de la casa: algunos grupos de desarrolladores ya usan una convención u otra.
  • Requisitos del lado del cliente: ¿Utilizará comillas dentro de las cadenas? (Ver la respuesta de Ady).
  • Lenguaje del lado del servidor: las personas de VB.Net pueden optar por usar comillas simples para java-script para que los scripts puedan construirse del lado del servidor (VB.Net usa comillas dobles para cadenas, por lo que las cadenas de java-script son fáciles de distinguir si usan comillas simples).
  • Código de biblioteca: si está utilizando una biblioteca que usa un estilo particular, puede considerar usar el mismo estilo usted mismo.
  • Preferencia personal: puede pensar que uno u otro estilo se ve mejor.
Kramii
fuente
No es cierto, 'está 00100111en binario, mientras que "está 00100010en binario. Por lo tanto, las comillas dobles requieren la mitad de energía para almacenar que las comillas simples. Esa es la diferencia allí mismo.
19

Veamos qué hace una referencia.

Dentro de jquery.js, cada cadena está entre comillas dobles.

Entonces, a partir de ahora, usaré cadenas entre comillas dobles. (¡Estaba usando single!)

Frederic
fuente
11
¿Por qué se vota esto? Esta es una cuestión de estilo y el mejor estilo es ser consistente y seguir a los que vinieron antes que usted.
Eric
2
+1 La documentación de la API jQuery también lo hace. Esta fue la única razón por la que me decidí por comillas dobles. Personalmente, creo que las respuestas de que "todo se reduce a la preferencia personal" son un poco defectuosas; lo mejor es descubrir una convención ampliamente utilizada y seguirla. Y dado que es posible que desee copiar y pegar ejemplos de jQuery (directa o indirectamente), no quiero tener que reemplazar las citas cada vez.
Steve Chambers
2
Quizás jQuery no pudo seguir a las personas antes que ellos (o realmente no le importó, como la mayoría de los otros expertos). ;)
James Wilkins
14

Solo mantén la consistencia en lo que usas. Pero no decepciones tu nivel de comodidad.

"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

Actualización ES6

Usando la sintaxis literal de la plantilla .

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

Es sobre todo una cuestión de estilo y preferencia. Hay algunas exploraciones técnicas bastante interesantes y útiles en las otras respuestas, por lo que quizás lo único que podría agregar es ofrecer un pequeño consejo mundano.

  • Si estás de codificación en una empresa o equipo, a continuación, que es probablemente una buena idea para seguir el "estilo de la casa".

  • Si estás solo hackeando algunos proyectos paralelos, entonces mira a algunos líderes prominentes en la comunidad. Por ejemplo, digamos que te estás metiendo en Node.js. Eche un vistazo a los módulos principales, por ejemplo, underscore.js o express y vea qué convención usan, y considere seguir eso.

  • Si ambas convenciones se usan por igual, entonces difiera a su
    preferencia personal .

  • Si usted no tiene ninguna preferencia personal, a continuación, lanza una moneda.

  • Si no tienes una moneda, entonces la cerveza está sobre mí;)

cabalgada
fuente
13

Espero no agregar algo obvio, pero he estado luchando con Django y Ajax y JSON en esto.

Suponiendo que en su código HTML use comillas dobles, como normalmente debería ser, sugiero usar comillas simples para el resto en JavaScript.

Así que estoy de acuerdo con @ady pero con algo de cuidado.

Mi conclusión es: en JavaScript, probablemente no importa, pero tan pronto como lo incrustas dentro de HTML o similar, empiezas a tener problemas. Debes saber lo que realmente está escapando, leyendo, pasando tu cadena.

Mi caso simple fue:

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>'

Puede detectar el \ 'en el tercer campo de showThis.

¡La cita doble no funcionó!

Está claro por qué, pero también está claro por qué debemos pegarnos entre comillas simples ... Supongo ...

Este caso es una incrustación HTML muy simple, el error fue generado por una simple copia / pegado de un código JavaScript 'doble comilla'.

Entonces para responder la pregunta:

Trate de usar comillas simples dentro de HTML. Podría ahorrar un par de problemas de depuración ...

Mario
fuente
1
Me encontré con un problema similar con la interpolación de cadenas ES6 (backticks). ¡Mi sistema de compilación lo compiló en una cadena entre comillas dobles, que rompió un encabezado Auth que había estado funcionando con comillas simples!
Jay
12

No estoy seguro de si esto es relevante en el mundo de hoy, pero las comillas dobles solían usarse para contenido que necesitaba procesar caracteres de control y comillas simples para cadenas que no lo tenían.

El compilador ejecutará la manipulación de cadenas en una cadena con comillas dobles mientras deja una cadena entre comillas literalmente intacta. Esto solía llevar a los desarrolladores 'buenos' a elegir el uso de comillas simples para cadenas que no contenían caracteres de control como \no \0(no procesados ​​dentro de comillas simples) y comillas dobles cuando necesitaban analizar la cadena (a un bajo costo en ciclos de CPU para procesamiento de la cadena).

garysb
fuente
14
No es que las cosas se hicieran de una manera y ahora se hagan de otra. Diferentes idiomas manejan las citas de manera diferente, y algunos funcionan como usted describe. Pero esta es una pregunta de JavaScript . Las comillas simples y dobles se tratan de manera idéntica en JavaScript (excepto para permitir que el otro tipo de comillas se use en una cadena sin escapar). No se trata de comillas dobles que permiten caracteres de control o interpolación de cadenas. JavaScript no funciona así. Los caracteres de control y las secuencias de escape funcionan del mismo tipo de cotización que utilice.
Michael Geary
Como ex programador de Perl, esto es lo que sigo pensando aunque sé que es irrelevante en JS.
zkent
12

Si está utilizando jshint , generará un error si utiliza una cadena de comillas dobles.

Lo utilicé a través del soporte de Yeoman de AngularJS, pero tal vez haya alguna forma de configurar esto.

Por cierto, cuando manejas HTML en JavaScript, es más fácil usar comillas simples:

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

Y al menos JSON está usando comillas dobles para representar cadenas.

No hay una forma trivial de responder a su pregunta.

MetallimaX
fuente
¿Ha cambiado la implementación jshint? dado que el sitio web de demostración parece aceptar sin lanzar advertencias / errores y tampoco puedo encontrar ninguna opción para restringir el uso de jshint. ¿Quizás esta respuesta está desactualizada o es inexacta?
Lea Hayes
Si jshint genera un error para una cadena entre comillas dobles, está seriamente roto. El estándar de JavaScript define lo que es correcto y no un linter roto.
Mecki
10

Hablando de rendimiento, las citas nunca serán su cuello de botella, sin embargo, el rendimiento es el mismo en ambos casos.

Hablando de la velocidad de codificación, si usa 'para delimitar una cadena, deberá escapar de las "comillas. Es más probable que necesite usar "dentro de la cadena, por ejemplo:

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

Entonces, prefiero usar 'para delimitar la cadena, por lo que tengo que escapar menos caracteres.

Juan C. Roldán
fuente
10

Una razón (tonta) para usar comillas simples sería que no requieren que presione la tecla Mayús para escribirlas, mientras que una comilla doble sí. (Supongo que la cadena promedio no requiere escapar, lo cual es una suposición razonable). Ahora, supongamos que cada día codifico 200 líneas de código. Quizás en esas 200 líneas tengo 30 citas. Quizás escribir una comilla doble toma 0.1 segundos más de tiempo que escribir una comilla simple (porque tengo que presionar la tecla Mayús). Luego, en cualquier día, pierdo 3 segundos. Si codifico de esta manera durante 200 días al año durante 40 años, entonces he perdido 6.7 horas de mi vida. Comida para el pensamiento.

John Kurlak
fuente
1
Supongo que solo te estás refiriendo a la distribución del teclado en inglés aquí ... Tengo uno alemán, tengo que presionar shift para ambos. De todos modos, no veo por qué presionar la tecla shift agrega tiempo al proceso. Aprieto shift con la mano izquierda y presiono la tecla de comillas con la derecha. Sucede al mismo tiempo, para mí no hay diferencia.
codewandler
1
@codewandler Todavía hay un costo de tener que presionar la tecla Mayús, incluso si se puede presionar en paralelo a la tecla ". Te obliga a mover un dedo fuera de su posición predeterminada. Por ejemplo, supongamos que está escribiendo: var description = "This is a \"quick\" test";en un teclado en inglés. Para un teclado en inglés, su dedo meñique debe moverse de la tecla de mayúsculas izquierda hacia la tecla Q en la fila superior en lugar de moverse de la tecla A a la tecla Q. En otras palabras, debe viajar el doble de distancia No estoy seguro de dónde están las teclas en el teclado alemán, pero estoy seguro de que hay un ejemplo análogo.
John Kurlak
2
@codewandler Además, tener que escribir shift, incluso si puedo hacerlo en paralelo, no permite que el dedo meñique izquierdo se prepare para escribir el siguiente carácter después de "en lo que sea que esté escribiendo."
John Kurlak,
1
La idea de "pérdida de tiempo" es un poco tonta, pero la idea de una tensión menos ergonómica (especialmente en la era del síndrome del túnel carpiano, etc.) hace que sea una buena ganancia, especialmente en los casos en que de otro modo no importa. Dadas más de 1,000 líneas de código por día, esto podría ahorrar cientos de curvas meñiques diarias.
Beejor
9

Examinando los pros y los contras

A favor de comillas simples

  • Menos desorden visual.
  • Generando HTML: los atributos HTML generalmente están delimitados por comillas dobles.

elem.innerHTML = '<a href="' + url + '">Hello</a>';
Sin embargo, las comillas simples son igual de legales en HTML.

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

Además, el HTML en línea es normalmente un antipatrón. Prefiero plantillas.

  • Generando JSON: Solo se permiten comillas dobles en JSON.

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

De nuevo, no debería tener que construir JSON de esta manera. JSON.stringify () suele ser suficiente. Si no, use plantillas.

A favor de comillas dobles

  • Los dobles son más fáciles de detectar si no tiene una codificación de colores. Como en un registro de consola o algún tipo de configuración de fuente de vista.
  • Similitud con otros lenguajes: en la programación de shell (Bash, etc.), existen literales de cadena entre comillas simples, pero los escapes no se interpretan dentro de ellos. C y Java usan comillas dobles para cadenas y comillas simples para caracteres.
  • Si desea que el código sea JSON válido, debe usar comillas dobles.

A favor de ambos

No hay diferencia entre los dos en JavaScript. Por lo tanto, puede usar lo que sea conveniente en este momento. Por ejemplo, los siguientes literales de cadena producen la misma cadena:

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

Comillas simples para cadenas internas y dobles para externas. Eso le permite distinguir las constantes internas de las cadenas que se mostrarán al usuario (o se escribirán en el disco, etc.). Obviamente, debe evitar poner el último en su código, pero eso no siempre se puede hacer.

Divyesh Kanzariya
fuente
8

Una cosa más que quizás desee considerar como una razón para el cambio de comillas dobles a comillas simples es el aumento de la popularidad de los scripts del lado del servidor. Al usar PHP, puede pasar variables y analizar funciones de JavaScript usando cadenas y variables en PHP.

Si escribe una cadena y usa comillas dobles para su PHP, no tendrá que escapar de ninguna de las comillas simples y PHP recuperará automáticamente el valor de las variables por usted.

Ejemplo: necesito ejecutar una función javascript usando una variable de mi servidor.

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

Esto me ahorra mucha molestia al tener que lidiar con unir cadenas, y puedo llamar efectivamente a un javascript desde PHP. Este es solo un ejemplo, pero esta puede ser una de varias razones por las cuales los programadores están predeterminados a comillas simples en javascript.

Cita de documentos PHP : "La característica más importante de las cadenas entre comillas dobles es el hecho de que los nombres de las variables se expandirán. Consulte el análisis de cadenas para obtener más detalles".

Dodzi Dzakuma
fuente
+1, hago esto en mi proyecto MVC.Net para que las comillas dobles de C # no interfieran con las comillas simples de javascript, y viceversa.
DCShannon
3
Creo que si está escribiendo JavaScript en su página desde un método de clase PHP, tiene mayores problemas.
BadHorsie
6

Hay personas que afirman ver diferencias de rendimiento: hilo antiguo de la lista de correo . Pero no pude encontrar ninguno de ellos para confirmar.

Lo principal es ver qué tipo de comillas (doble o simple) está utilizando dentro de su cadena. Ayuda a mantener baja la cantidad de escapes. Por ejemplo, cuando trabaja con html dentro de sus cadenas, es más fácil usar comillas simples para que no tenga que escapar de todas las comillas dobles alrededor de los atributos.

Michiel Overeem
fuente
Aunque los atributos también pueden estar rodeados de comillas simples :)
Damir Zekić
A la derecha, pensé que xml y xhtml prescriben comillas dobles que rodean los atributos, pero se permiten comillas simples.
Michiel Overeem
6

Usaría comillas dobles cuando no se pueden usar comillas simples y viceversa:

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

En vez de:

'\'' + singleQuotedValue + '\''
"\"" + doubleQuotedValue + "\""
Gumbo
fuente
¿Qué pasa con una cadena que contiene comillas simples y comillas dobles como O'rea "lly
sudhAnsu63
6

No hay diferencia entre comillas simples y dobles en JavaScript.

La especificación es importante:

Quizás haya diferencias de rendimiento, pero son absolutamente mínimas y pueden cambiar todos los días según la implementación de los navegadores. La discusión adicional es inútil a menos que su aplicación de JavaScript tenga cientos de miles de extensión.

Es como un punto de referencia si

a=b;

es más rápido que

a = b;

(espacios extra)

hoy, en un navegador y plataforma en particular, etc.

mauro
fuente
2
Sin espacios es más rápido. menos caracteres para analizar en la cadena. : p
pilavdzice
6

Cuando uso CoffeeScript, uso comillas dobles. Estoy de acuerdo en que debe elegir cualquiera de ellos y atenerse a él. CoffeeScript le ofrece interpolación cuando usa comillas dobles.

"This is my #{name}"

ES6 está utilizando ticks de retroceso (`) para cadenas de plantillas. Lo que probablemente tiene una buena razón, pero al codificar puede ser engorroso cambiar el carácter de los literales de cadena de comillas o comillas dobles a ticks de retroceso para obtener la función de interpolación. Puede que CoffeeScript no sea perfecto, pero usar el mismo carácter de cadena literal en todas partes (comillas dobles) y poder interpolar siempre es una buena característica.

`This is my ${name}`
GijsjanB
fuente
Para mí, la marca de vuelta es un claro ganador en este concurso, (casi) no hay presencia dentro de cadenas de texto comunes, más interpolación var
Simone Poggi
5

Si está retrocediendo entre JavaScript y C #, es mejor entrenar sus dedos para la convención común que es comillas dobles.

moomoo
fuente
5

He estado ejecutando lo siguiente unas 20 veces. Y parece que las comillas dobles son aproximadamente un 20% más rápidas.

La parte divertida es que, si cambia la parte 2 y la parte 1, las comillas simples son aproximadamente un 20% más rápidas.

//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));
Bastiaan Linders
fuente
31
Dicho de otra manera, descubrió que el código posterior se ejecuta más rápido. Este es el problema al hacer micro benchmarks. Debe tener en cuenta el motor JS que optimiza el código a medida que se ejecuta. (Verás este mismo efecto cuando compares Java debido a cómo funciona el JIT.)
David Phillips
44
primera fecha nueva es lenta, agregue var dummy_date = new Date()al comienzo
Lauri
1
El nivel de micro-optimización aquí es tan tonto que también se podría argumentar que las comillas simples son más rápidas de escribir, lo que lleva a un desarrollo más rápido.
Beejor
4

No hay estrictamente ninguna diferencia, por lo que es principalmente una cuestión de gusto y de lo que está en la cadena (o si el código JS en sí está en una cadena), para mantener baja la cantidad de escapes.

La leyenda de la diferencia de velocidad podría provenir del mundo PHP, donde las dos citas tienen un comportamiento diferente.

PhiLho
fuente
Y Ruby, puedo agregar. Python tiene el mismo comportamiento que JavaScript: no hay diferencia entre comillas simples / dobles.
Damir Zekić
4

Después de leer todas las respuestas que dicen que puede ser más rápido o tener ventajas, diría que las comillas dobles son mejores o más rápidas porque el compilador de cierre de Google convierte las comillas simples en comillas dobles.

Mohsen
fuente
¿Sabes por qué hace eso?
ma11hew28
No lo sé. Tal vez sea una convención de codificación y nada especial.
Mohsen
4

Ahora que es 2020, deberíamos considerar una tercera opción para Javascript: la única opción para todo.

Esto se puede usar en todas partes en lugar de comillas simples o dobles.

¡Te permite hacer todas las cosas!

  1. Incruste comillas simples dentro de él: "¡Es genial!"
  2. Incruste comillas dobles dentro de él: `¡Es" realmente "genial!
  3. Utilice la interpolación de cadenas: `¡Es" $ {mejor} "que genial!`
  4. Permite múltiples líneas: `

    Esta

    Hace

    Javascript

    ¡Mejor!

    ``

Tampoco causa ninguna pérdida de rendimiento al reemplazar los otros dos: https://medium.com/javascript-in-plain-english/are-backticks-slower-than-other-strings-in-javascript-ce4abf9b9fa

OCDev
fuente
3

Si su fuente JS es:

elem.innerHTML="<img src='smily' alt='It\'s a Smily' style='width:50px'>";

La fuente HTML será:

<img src="smiley" alt="It's a Smiley" style="width:50px">

o para HTML5

<img src=smiley alt="It's a Smiley" style=width:50px>

JS permite matrices como esa:

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

Pero si lo cadenas, será por razones compatibles:

JSON=["this","that"]

Estoy seguro de que esto lleva algo de tiempo.

BF
fuente
3

Solo para agregar mis 2 centavos: Al trabajar con JS y PHP hace unos años, me he acostumbrado a usar comillas simples para poder escribir el carácter de escape ('\') sin tener que escapar también. Usualmente lo usaba cuando escribía cadenas crudas con rutas de archivos, etc. ( http://en.wikipedia.org/wiki/String_literal#Raw_strings )

De todos modos, mi convención terminó convirtiéndose en el uso de comillas simples en cadenas sin procesar de tipo identificador, como if (typeof s == 'string') ...(en las que nunca se usarían caracteres de escape, nunca), y comillas dobles para textos , como "Hey, ¿qué pasa?". También uso comillas simples en los comentarios como una convención tipográfica para mostrar los nombres de los identificadores. Esto es solo una regla general, y me separo solo cuando es necesario, como al escribir cadenas HTML '<a href="#"> like so <a>'(aunque también podría revertir las comillas aquí). También soy consciente de que, en el caso de JSON, se usan comillas dobles para los nombres, pero aparte de eso, personalmente, prefiero las comillas simples cuando nunca se requiere escapar para el texto entre las comillas, comodocument.createElement('div') .

En pocas palabras, y como algunos han mencionado / aludido, elija una convención, cumpla con ella y solo se desvíe cuando sea necesario.

James Wilkins
fuente