¿Por qué el cambio reciente a eliminar / omitir puntos y comas de Javascript?

Parece que está de moda recientemente omitir punto y coma de Javascript. Hubo una publicación en el blog hace unos años enfatizando que en Javascript, los puntos y comas son opcionales y la esencia de la publicación parece ser que no debes molestarte con ellos porque son innecesarios. La publicación, ampliamente citada, no da ninguna razón convincente para no usarlos, solo que dejarlos fuera tiene pocos efectos secundarios.

Incluso GitHub se ha subido al carro sin punto y coma, requiriendo su omisión en cualquier código desarrollado internamente, y un compromiso reciente con el proyecto zepto.js por parte de su mantenedor ha eliminado todos los puntos y coma de la base de código. Sus principales justificaciones fueron:

• Es una cuestión de preferencia para su equipo;
• menos mecanografía

¿Hay otras buenas razones para dejarlos fuera?

Francamente, no veo ninguna razón para omitirlos, y ciertamente no hay razón para volver sobre el código para borrarlos. También va en contra de ( años de ) práctica recomendada , para lo cual realmente no compro el argumento del "culto a la carga". Entonces, ¿por qué todo el reciente punto y coma de odio? ¿Hay una escasez inminente? ¿O es solo la última moda de Javascript?

Supongo que mi razón es la más floja: programo en muchos idiomas diferentes 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, siempre agrego el ';'

La otra razón es la documentación: agregando ';' Me estoy declarando explícitamente dónde espero que termine la declaración. Por otra parte, yo uso {} todo el tiempo también.

Todo el argumento de conteo de bytes me parece irritante e inútil:

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 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 de los 100 mejores, como Twitter, Google, Yahoo, etc. tal vez. El resto de nosotros debería preocuparnos por la calidad del código, no por las guerras religiosas de punto y coma.

Hace que el método de encadenamiento sea más fácil y commit diffs más limpio

Digamos que estoy preguntando y tengo

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

Si quiero agregar cosas y mantener mi commit basado en líneas pequeño , tengo que agregarlo arriba del atributo. Por lo tanto, es un pensamiento más largo que simplemente "agregar al final". ¿Y quién quiere pensar? =)

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

Pero, cuando dejo caer los punto y coma, solo puedo agregar y llamarlo un día

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

Además, si decido utilizar el último método, no tengo que reasignar el punto y coma y contaminar mi confirmación nuevamente.

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

Versus the uggo

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

los punto y coma en JavaScript son opcionales

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

Cuando uso punto y coma, olvido el 2% de ellos y tengo que revisarlos / agregarlos constantemente.

Cuando no uso puntos y comas nunca pongo uno accidentalmente, así que nunca tengo que verificarlos / eliminarlos.

Recientemente escribí un analizador / analizador para JavaScript, donde tuve que implementar minuciosamente ASI, y también tengo mi copia de Crockford's JavaScript: The Good Parts en mi estantería, que aboga siempre por el uso de 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 potente, también es un lenguaje para principiantes y buena suerte para explicar esto a alguien que está aprendiendo qué es un forbucle. Al igual que presentarle a la mayoría de las personas una nueva habilidad, hay algunas cosas más complejas que no desea explicar de inmediato, por lo que elige inculcar una creencia de "culto de carga" en ciertas cosas solo para despegarlas. Entonces, tiene dos opciones al enseñar a un principiante cómo escribir JavaScript:

1. Dígales que "sigan esta regla y no pregunten por qué", diciéndoles que pongan un punto y coma siempre al final de cada línea. Desafortunadamente, esto no ayuda en el ejemplo anterior, ni en ningún otro ejemplo en el que ASI se interponga en el camino. Y el programador principiante Sr. o Sra. Se confunde cuando falla el código anterior.
2. Dígales que "sigan estas dos reglas y no pregunten por qué", diciéndoles que no se molesten con punto y coma al final de cada línea, y que siempre a) Siga returncon a {, y b) Cuando una línea comienza con a (, anteponga con un ;.

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

No existe la sobrecarga de información, solo un mal diseño.

- Edward Tufte

Es una regla general en el diseño gráfico dejar de lado elementos innecesarios y ornamentación para reducir el ruido.

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

let foo = 1

vs.

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

Un ejemplo exagerado, por supuesto, pero ilustra el principio general: deben agregarse elementos visuales adicionales si y solo sirven para un propósito. Entonces, ¿los puntos y comas tienen un propósito?

Las razones históricas para usar punto y coma en JavaScript fueron:

• Mantener similitud con C / Java
• Evite problemas de compatibilidad con navegadores y herramientas mal escritos
• Ayudando a humanos y máquinas a detectar errores de código
• La inserción automática de punto y coma conlleva una penalización de rendimiento

Los problemas de compatibilidad no son un problema hoy en día. Las linters modernas pueden detectar cualquier error de código igual de bien sin punto y coma. La similitud con C / Java / PHP aún puede ser una consideración (ver la respuesta aceptada por Pat), pero el hecho de que otros lenguajes contengan 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 hubo una penalización de rendimiento en V8. Esto es Io.js que analiza un archivo JavaScript de 41 MB (Lodash repite 100 veces) con punto y coma y luego con punto y coma eliminados:

$ 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

Todos tienen que decidir su propio estilo de codificación preferido para sus proyectos, pero ya no veo ningún beneficio tangible en el uso de punto y coma, así que para reducir el ruido visual, me detuve.

Elegir una convención de programación es efectivamente 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., al tiempo que sacrificamos la flexibilidad. Estas razones son razones comerciales reales.

Razones 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 acelerar JavaScript en forma muy rápida, por lo que era ventajoso aprovechar un subconjunto limitado del idioma. Así que elegí el subconjunto JSLint de JavaScript, activé las aplicaciones Rockstar JSLinter en Eclipse con la configuración más restrictiva que pude 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 muy alta y esos detalles no ayudar a hacer 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 idiomas ayuda a reforzar este imperativo. Y aunque esto puede no ayudar a responder la pregunta del OP, creo que podría ayudar con la formulación práctica de la misma.

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

Minificación: si minimiza un fragmento de JavaScript que no termina explícitamente las declaraciones con un carácter de punto y coma, podría terminar teniendo dificultades para tratar de descubrir qué está mal con un fragmento que estaba funcionando antes de la minificación Y ahora no funciona.

Ambigüedad: los punto y coma son opcionales, es cierto, sin embargo, al eliminarlos del código fuente, puede dejar algunos escenarios ambiguos para que el analizador decida por sí mismo. Si está escribiendo 100 líneas de código para una tienda en línea, sí, tal vez no importe, pero las tareas más serias requerirían una claridad del 100%.

Hace mucho tiempo leí una analogía muy agradable sobre algo más, pero también es muy cierto en este caso: (En nuestro caso) Eliminar los punto y coma es como cruzar en un semáforo en rojo. Puede que al final estés bien o que un camión te golpee.

¿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 comunidad de JavaScript. En nuestro caso, obviamente nadie va a minimizar el JavaScript en el lado del servidor (ya que no se supone que el código fuente se envíe 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, lamentablemente 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 dentro.

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

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

JSLint no lo aprueba.

JavaScript no ha necesitado punto y coma para terminar 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 qué JavaScript necesitaría el uso frecuente de punto y coma, pero no otros lenguajes declarativos interpretados como Ruby o Python.

Requerir punto y coma puede facilitar la escritura de un analizador de un idioma, pero si todos los intérpretes respaldan la omisión de punto y coma, ¿cuál es exactamente el punto?

Todo se reduce a lo informado que es un programador: si sabe que puede omitir un punto y coma, siéntase libre de hacerlo entendiendo que puede o no haber una consecuencia. Los seres humanos son máquinas de toma de decisiones y casi todas las decisiones requieren cierto compromiso o compensación. La desventaja de simplemente lanzar puntos y comas 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 le pregunte) y JSLint no se quejará (a quién le importa ) Por otro lado, la desventaja de omitir los punto y coma es el hecho de que el 90% de los programadores de JavaScript lo castigarán por ello, pero puede terminar disfrutando más escribiendo JavaScript debido a eso.

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

Tengo dos teorías:

UNA)

Lo importante de esta elección es que, en el pasado, cuando JSLint, etc., eran aplicables, elegía pasar una gran cantidad de tiempo detectando errores de sintaxis oscuros, o una cantidad razonable de tiempo aplicando una política de estándares en el código.

Sin embargo, a medida que avanzamos más hacia el código impulsado por Test Unit y la integración continua, la cantidad de tiempo (y la interacción humana) requerida para detectar un error de sintaxis ha disminuido masivamente. La retroalimentación de las pruebas indicará rápidamente si su código funciona como se esperaba, mucho antes de que se acerque a un usuario final, entonces, ¿por qué perder el tiempo agregando verbosidad opcional?

SI)

Los programadores perezosos harán cualquier cosa para facilitar sus propias vidas a corto plazo. Menos tipeo -> menos esfuerzo -> más fácil. (además, no tener punto y coma evitará forzar el dedo anular derecho, evitando algo de RSI).

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

No los dejo afuera, pero cambio las reglas cuando los inserto.

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

• Antes de que termine cada línea
• Excepto que la línea termina con un }enunciado de una 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 un paréntesis / paréntesis 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 comas hace que sea fácil encontrar errores hechos al dejarlos fuera.

Otro argumento es que el return\nvalueerror infame proviene de no saber acerca de ASI. Mi regla te obliga a saber sobre 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á, 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. Mi suposición es que es más una medida de seguridad que un simple requisito programático. De alguna manera, esto reduciría significativamente XSS cuando se convierte en un requisito en lugar de una sugerencia.