¿Por qué el cambio reciente a la eliminación / omisión de puntos y coma de Javascript?

Supongo que mi razón es la más sencilla: programo en demasiados idiomas al mismo tiempo (Java, Javascript, PHP), que requieren ';' así que en lugar de entrenar mis dedos y ojos que el ';' no es necesario para javascript, simplemente siempre agrego el ';'

La otra razón es la documentación: agregando el ';' Me estoy declarando explícitamente a mí mismo dónde espero que termine la declaración. Entonces otra vez uso {} todo el tiempo también.

Todo el argumento de la cuenta de bytes me parece irritante y sin sentido:

1) para bibliotecas comunes como jquery: use el CDN de Google y la biblioteca probablemente ya estará en el caché del navegador

2) versione sus propias bibliotecas y configúrelas para que se almacenen en caché para siempre.

3) gzip y minimizar si es realmente, realmente necesario.

¿Pero realmente cuántos sitios tienen como su mayor cuello de botella la velocidad de descarga de su javascript? Si trabaja para un sitio top 100 como twitter, google, yahoo, etc. tal vez. El resto de nosotros solo debemos preocuparnos por la calidad del código y no por las guerras religiosas de punto y coma.

Hace que el encadenamiento de métodos sea más fácil y comprometa a eliminar las diferencias

Así que digamos que estoy jQuerying y tengo

$('some fancy selector')
  .addClass()
  .attr();

Si quiero agregar cosas y mantener mi diferencia de confirmación basada en línea , tengo que agregarla encima de attr. Así que es un pensamiento más largo que solo "agregar al final". ¿Y quién quiere pensar? =)

$('some fancy selector')
  .addClass()
  // new method calls must go here
  .attr();

Pero, cuando suelto los puntos y coma, puedo agregarlos y llamarlos un día

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate()
+   .click()

Además, si decido quitar el último método, no tengo que volver a asignar el punto y coma y volver a contaminar mi confirmación.

  $('some fancy selector')
    .addClass()
    .attr()
    .animate()
-   .click()

Versus the uggo

  $('some fancy selector')
    .addClass()
    .attr()
+   .animate();
-   .animate()
-   .click();

los puntos y comas en JavaScript son opcionales

Mi razón personal para no usar punto y coma es el TOC.

Cuando uso los puntos y coma, me olvido del 2% de ellos y tengo que revisarlos / agregarlos constantemente.

Cuando no uso punto y coma, nunca puse uno por accidente, así que nunca tengo que marcarlos / quitarlos.

Recientemente escribí un analizador / analizador para JavaScript, en el que tuve que implementar ASI con esmero, y también tengo mi copia del JavaScript: The Good Parts de Crockford en mi estante, que defiende siempre usando punto y coma. La intención era buena, pero no siempre ayuda en la práctica.

Obviamente, las personas que escriben marcos como jQuery, zepto, etc. son maestros de sintaxis de JavaScript y, por lo tanto, saben la diferencia entre:

return
{
    status: true
};

y

return {
    status: true
};

JavaScript, aunque es potente, también es un lenguaje para principiantes y buena suerte al explicárselo a alguien que está aprendiendo qué es un bucle for . Al igual que la introducción de habilidades nuevas para la mayoría de las personas, hay algunas cosas más complejas que no quieres explicar de inmediato, por lo que, en cambio, eliges inculcar la creencia del "culto de la carga" en ciertas cosas solo para despegar. Entonces, tienes dos opciones cuando le enseñas a un principiante cómo escribir JavaScript:

1. Dígales "siga esta regla y no pregunte por qué", y dígales que pongan un punto y coma siempre al final de cada línea. Desafortunadamente, esto no ayuda en el ejemplo anterior, o en cualquier otro ejemplo en el que ASI se interponga en el camino. Y el programador principiante del Sr. o la Sra. Se confunde cuando falla el código anterior.
2. Dígales "siga estas dos reglas y no pregunte por qué", indíqueles que no se molesten con punto y coma al final de cada línea y que, en su lugar, siempre a) Siga return con a { , y b) Cuando una línea comienza con un ( , prepárela con un ; .

Elegir la opción 2 es un mejor conjunto de reglas de "culto a la carga" a seguir (dará como resultado muy pocos errores relacionados con ASI), e incluso si obtiene una comprensión profunda del tema, tiene menos caracteres innecesarios en el pantalla.

  

No existe tal cosa como sobrecarga de información, solo mal diseño.

     

- Edward Tufte

Es un regla general en diseño gráfico para dejar de lado elementos innecesarios y ornamentos para reducir el ruido.

Menos elementos visuales en la pantalla significa menos trabajo para que nuestros cerebros analicen la información útil real.

let foo = 1

vs.

let /* variable */ foo = 1; // EOL

Un ejemplo exagerado, por supuesto, pero ilustra el principio general: se deben agregar elementos visuales adicionales si y solo si cumplen un propósito. Entonces, ¿los puntos y coma sirven un propósito?

Las razones históricas para utilizar puntos y coma en JavaScript fueron:

• Mantenga la similitud con C / Java
• Evite los problemas de compatibilidad con navegadores y herramientas mal escritos
• Ayudar a los humanos y las máquinas a detectar errores de código
• La inserción automática de punto y coma lleva una penalización de rendimiento

Los problemas de compatibilidad son prácticamente un problema hoy en día. Los linters modernos pueden detectar cualquier error de código también sin punto y coma. La similitud con C / Java / PHP aún puede ser una consideración (consulte la respuesta aceptada por Pat), pero solo porque otros lenguajes contienen elementos de sintaxis superfluos, no significa que debamos mantenerlos en JavaScript, especialmente porque muchos otros lenguajes (Coffeescript, Python, Ruby, Scala, Lua) no los requieren.

Hice una prueba rápida para ver si había una penalización de rendimiento en V8. Esto es Io.js analizando un archivo JavaScript de 41 MB (Lodash se repitió 100 veces) con punto y coma y luego con punto y coma eliminado:

$ time node lodashx100.js
node lodashx100.js  2.34s user 1.30s system 99% cpu 3.664 total
$ time node lodashx100s.js
node lodashx100s.js  2.34s user 1.15s system 99% cpu 3.521 total

Todo el mundo tiene que decidir su propio estilo de codificación preferido para sus proyectos, pero ya no veo ningún beneficio tangible en el uso de puntos y coma, por lo que para reducir el ruido visual, me detengo.

Elegir una convención de programación es en realidad lo mismo que elegir un subconjunto del idioma de destino. Todos hacemos esto por las razones habituales: legibilidad del código, mantenibilidad, estabilidad, portabilidad, etc., a la vez que se sacrifica la flexibilidad. Estas razones son verdaderas razones de negocios.

Las razones tales como "guardar pulsaciones de teclas" y "los programadores deben aprender las reglas de JavaScript" son razones comerciales marginales, por lo que tienen poco peso práctico.

En mi caso, necesitaba llegar a la velocidad de JavaScript muy rápido, por lo que aprovechar un subconjunto limitado del idioma era una ventaja para mí. Así que elegí el subconjunto JSLint de JavaScript, activé la aplicación JSLinter de Rockstar en Eclipse a la configuración más restrictiva que podía soportar y no he mirado atrás.

Estoy agradecido de poder evitar los detalles de la diferencia entre "==" y "===", o los detalles de la inserción de punto y coma, porque ya tengo una lista de tareas de una milla de alto y esos detalles no ayudará a terminar esos trabajos un segundo antes.

Por supuesto, lo más importante de una convención es la coherencia, y pensar en ella como un subconjunto de lenguaje ayuda a reforzar este imperativo. Y aunque esto no ayude a responder la pregunta del OP, creo que podría ayudar con el encuadre práctico.

Una pregunta bastante antigua, sin embargo, me sorprende que nadie haya mencionado:

Minificación: Si minimiza un fragmento de código JavaScript que no finaliza explícitamente las declaraciones con un carácter de punto y coma, es posible que tenga dificultades para descubrir qué es lo que está mal. con un fragmento que estaba funcionando antes de la reducción y ahora no funciona.

Ambigüedad: los puntos y coma son opcionales, es cierto; sin embargo, al eliminarlos del código fuente, puede dejar algunos escenarios ambiguos al analizador para que decida por sí solo. Si está escribiendo un código de 100 líneas para una tienda en línea, sí, quizás no importa, pero las tareas más serias requieren una claridad del 100%.

Hace mucho tiempo leí una muy buena analogía sobre otra cosa, pero también es muy cierto en este caso: (En nuestro caso) Eliminar los puntos y comas es como cruzar en un semáforo en rojo. Es posible que al final estés bien o te atropelle un camión.

¿Por qué se está volviendo más popular en estos días?

Personalmente, creo que tener JavaScript ejecutado en el lado del servidor tuvo muchos efectos en la propia comunidad de JavaScript. En nuestro caso, obviamente, nadie va a minimizar el JavaScript en el lado del servidor (ya que se supone que el código fuente no se envía al navegador web del cliente), por lo que no tener punto y coma parece mucho más seguro, lo cual es cierto; sin embargo, los otros desarrolladores que aprenden de estos libros, artículos y videos, desafortunadamente descartan el hecho de que JavaScript en el lado del servidor no es exactamente lo mismo que JavaScript en el lado del cliente.

Hay buenas razones para mantenerlos.

No son realmente opcionales, JS puede volver a agregarlos con inserción de punto y coma automática cuando faltan, pero eso no es lo mismo.

JavaScript de Douglas Crockford: The Good Parts dice en dos ocasiones distintas que es una mala idea. La inserción automática de punto y coma puede ocultar errores en su programa y crear ambigüedad.

JSLint no aprueba.

JavaScript no ha necesitado puntos y coma para terminar las declaraciones en más de una década. Esto se debe a que los caracteres de nueva línea se consideran terminadores de sentencias (creo que esto también se menciona en las primeras especificaciones de ECMAScript). Realmente tiene mucho sentido, especialmente porque realmente no hay una buena razón [que yo sepa] por la cual JavaScript necesitaría el uso frecuente de punto y coma, pero no otros idiomas declarativos interpretados como Ruby o Python.

Requerir puntos y coma puede hacer que sea más fácil escribir un analizador para un idioma, pero si cada intérprete soporta la omisión de los puntos y coma, ¿cuál es exactamente el punto?

Todo se reduce a lo bien que sabe un programador: si sabe que puede omitir un punto y coma, siéntase libre de hacerlo entendiendo que puede haber o no una consecuencia. Los seres humanos son máquinas que toman decisiones y casi todas las decisiones requieren algún compromiso o compensación. La compensación a solo lanzar puntos y coma alrededor de su código (incluso en lugares donde no son necesarios) es que su código se vuelve menos legible (dependiendo de a quién pregunte) y JSLint no se quejará (a quién le importa). ). Por otro lado, la desventaja de omitir los puntos y comas es el hecho de que el 90% de los programadores de JavaScript lo castigarán por ello, pero es posible que termine disfrutando de la escritura de JavaScript más debido a ello.

Qué te suena mejor; ¿Tomar decisiones informadas o tomar decisiones ciegas / mentalidad de rebaño?

Tengo dos teorías:

A)

Lo importante de esta elección es que en el pasado, cuando JSLint, etc., era aplicable, elegía dedicar una gran cantidad de tiempo a detectar errores de sintaxis poco claros, o una cantidad razonable de tiempo para hacer cumplir una política de normas en el código.

Sin embargo, a medida que avanzamos más hacia Prueba unitaria , el código impulsado y la integración continua la cantidad de tiempo (y la interacción humana) requeridos Para atrapar un error de sintaxis ha disminuido masivamente. Los comentarios de las pruebas indicarán rápidamente si su código funciona como se esperaba, mucho antes de que se acerque al usuario final, así que, ¿por qué perder el tiempo agregando verbosidad opcional?

B)

Los programadores perezosos harán cualquier cosa para facilitar sus propias vidas en el corto plazo. Menos mecanografía - > menos esfuerzo - > más fácil. (Además, no tener que hacer un punto y coma evitará forzar el dedo anular de la mano derecha, evitando algo de RSI).

(Nota: no estoy de acuerdo con la idea de omitir algo que desambigua una declaración).

No los dejo, pero cambio las reglas cuando se insertan.

Las reglas que la mayoría de la gente usa es

• Antes de que cada línea termine
• Excepto que la línea termina con un } proveniente de una declaración de función
• Pero solo una declaración de función, no una asignación a una función literal

Mi regla es: al comienzo de cada línea que comienza con una abrazadera / corchete de apertura.

El mío es más simple, por lo tanto, más fácil de seguir y menos propenso a los errores. Además, el bajo número de puntos y coma hace que sea más fácil encontrar errores que se cometen al omitirlo.

Otro argumento es que el error return\nvalue proviene de no saber acerca de ASI. Mi regla te obliga a conocer ASI, por lo que es menos probable que las personas que usan mi regla caigan en la trampa de ese error.

Recuento de bytes. Verás, las personas malintencionadas generalmente intentan encajar tanto en una sola línea de código. Técnicamente hablando, esto no sería posible sin punto y coma. Supongo que es más una medida de seguridad que un simple requisito programático. De alguna manera, esto reduciría significativamente el XSS cuando se convierte en un requisito en lugar de una sugerencia.