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

80

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?

Jonathan
fuente
2
"años de práctica recomendada" se refieren una cuestión de la lista negra etiqueta de encuestas SO , que hace que sea poco probable autorizada para soportar cualquier tipo de opinión
mosquito
24
@gnat solo porque la gente odia la pregunta sobre SO no lo convierte en una fuente menos válida de la opinión de la gente.
Ryathal
3
@gnat Las preguntas que "oficialmente se consideran inapropiadas en StackOverflow" a veces son consideradas muy autorizadas por la comunidad de expertos. Triste pero cierto.
MarkJ
44
@gnat La pregunta en la lista negra en realidad tiene algunos ejemplos muy interesantes de por qué omitir ;puede romper su código. Entonces diría que es una referencia útil para esta pregunta.
Andres F.
1
Esto podría estar relacionado con la creciente prominencia de los hipsters a principios de la década de 2010.
Alex

Respuestas:

62

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.

Palmadita
fuente
3
Supongo que lo contrario también podría ser cierto. A medida que Python se vuelve más popular para la web, es más fácil que su JS se parezca a Python.
Ben DeMott
44
Inténtalo, pero los mismos guerreros de byte me perseguirían por espacios en blanco innecesarios al comienzo de las líneas. (También tendría errores de Javascript porque confiaría en la regla de sangría de Python en lugar de usar {}
Pat
66
Si es importante reducir el recuento de bytes, tendrá algo que minimiza los archivos tanto como sea posible. Si aún no vale la pena usar un minimizador, entonces no vale la pena preocuparse por eliminar ';' para ahorrar en el recuento de bytes.
Lawtonfogle
3
el recuento de bytes no se reduce necesariamente, de hecho, se puede aumentar ya que una nueva línea a menudo (no siempre) en realidad son dos caracteres (nueva línea seguida de retorno de carro), por lo que en su forma más eficiente en el espacio, la nueva la línea será una vez el mismo carácter que un punto y coma de un carácter (si compacta todo su código JS en una línea, que a menudo se realiza para el código JS desplegado, no para el código fuente de desarrollo).
ALXGTV
Los humanos necesitan sangría para comprender el anidamiento profundo, que requiere más bytes que punto y coma. Sin embargo, los punto y coma son desechos que distraen las pulsaciones de teclas.
Cees Timmerman
39

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();
Mark Canlas
fuente
37
Este es un caso de uso de nicho de la OMI.
JBRWilkinson
99
Pero interesante sin embargo.
Jonathan
8
Puede tener punto y coma al final en una nueva línea sangrada como la línea de inicio. Luego copia y reordena las cosas como lo desee. Esto también cierra la cadena muy bien.
Nux
11
¿Soy yo quien se pregunta por qué a alguien le importaría lo bien que se vean las diferencias de sus compromisos? Como regla general, la gente lee el código, no las diferencias.
Jules
11
@Jules, las diferencias de limpieza significan que las fusiones tienen más probabilidades de tener éxito.
joeytwiddle
22

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.

Raynos
fuente
3
Bueno uno Me quemé con una o dos líneas sin punto y coma en un archivo que, por lo demás, tenía un punto y coma correcto.
Jonathan
3
Hay analizadores (por ejemplo, GeSHi) que no analizarán su código correctamente si no hay puntos y comas. Se podría decir que los humanos no cometerán tales errores ... Pero en serio, si todo su equipo lograra recordar dónde deben ponerse absolutamente los puntos y comas, ¿realmente cree que lo recordarán sin el café de la mañana? Y codificarán en muchos estados mentales. Asegúrate de ello.
Nux
16

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.

Kevin McCormick
fuente
8
Está bien, voy a morder. Ayúdame a comprender la diferencia de sintaxis entre los dos ejemplos anteriores. Mi ojo inexperto solo ve una diferencia en el formato.
Jesse C. Slicer
99
O, por otro lado, me topé con la respuesta por puro accidente. En el primer ejemplo, returnse considera una declaración solitaria y el final de línea es el equivalente de un punto y coma. El segundo ejemplo en realidad devuelve el objeto. Tramposo
Jesse C. Slicer
99
No creo estar de acuerdo con la idea de que JavaScript es un lenguaje para principiantes, hay muchas inconsistencias y efectos sorpresa en JavaScript que no tienen explicaciones simples. En mi opinión, un idioma para principiantes no sería así, llamaría a JavaScript un idioma intermedio.
Ryathal
2
@Ryathal Entiendo a qué te refieres, pero llamarlo un idioma intermedio hace que me pregunte en qué idiomas interviene. Lo haces sonar como si fuera un paso en un viaje a otra cosa en lugar de un destino en sí mismo.
Racheet
99
Punto de aclaración: el returnejemplo es en realidad una excepción al comportamiento normal de JS que consiste en intentar unir líneas cuando se omite un punto y coma. return, breaky continuetodos exhiben este comportamiento excepcional en el que una nueva línea final siempre se interpreta como un final de declaración. (La fuente es "JavaScript: la guía definitiva" de Flanagan, pp25-26). Personalmente, me esfuerzo por la idea del "código de menor sorpresa". Dejar los puntos y comas tiende a dar lugar a más sorpresas que cualquier otra cosa (generalmente también mantengo mis llaves incluso para declaraciones simples).
Kyle
16

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.

justmoon
fuente
Contrarrestaría este argumento de omitir elementos innecesarios en la carga que la mente tiene que hacer ahora para volver a agregar en la sintaxis opcional. Ahora el punto y coma no es una gran tensión mental si se omite. Este es un problema que he experimentado con Ruby y Scala. Cuando se convierte en una cadena de llamadas con llamadas dentro de las llamadas, y todas han omitido cada par, es una carga separarlas.
Seamus
8

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.

mjhm
fuente
5

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.

53777A
fuente
Los minificadores podrían dejar líneas nuevas de un solo carácter o insertar puntos y coma cuando los puntos y coma no están presentes sin una penalización de tamaño. No sé qué (si alguno) minificadores hacen esto. El peligro todavía existe en al menos algunos de ellos, por lo que su punto aún se mantiene en la práctica.
outis
3

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.

Encaitar
fuente
3

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?

Ravenstine
fuente
Me interesaría saber por qué esto ha recibido votos negativos. JavaScript no necesita punto y coma para terminar las declaraciones; ciertamente puede usarlos, pero de ninguna manera son un requisito. Si fueran necesarios, las explicaciones de nadie más funcionarían. El hecho (sí, un hecho) de que puede escribir una aplicación JavaScript completa con pocos o ningún punto y coma lo demuestra. Más allá de eso, no veo cómo entender de qué manera funciona una herramienta y usar el propio razonamiento para tomar decisiones es de alguna manera objetable en contraste con "simplemente hazlo". Eso es lo que se conoce como religión.
Ravenstine
No voté en contra, pero el problema podría ser que esto no es correcto como está escrito. Las nuevas líneas no se consideran terminadores de declaraciones en javascript. Puede dejar de punto y coma debido a una característica llamada inserción automática de punto y coma que le permite corregir errores de análisis automáticamente en ciertas circunstancias. Las personas que abogan por el punto y coma argumentan que muchos programadores de JavaScript parecen entender mal esta regla. Su publicación parece ser un argumento a su favor en ese sentido. (Para ser justos, estoy mayormente de acuerdo con su tesis, pero por diferentes razones)
Tim Seguine
@TimSeguine Sí, escribí esto antes de tener una mejor comprensión. Todavía no creo que sea objetivamente incorrecto no usar punto y coma, siempre y cuando las personas que lo hacen entiendan qué es exactamente lo que están haciendo. Debería reelaborar mi publicación, o tal vez deshacerme de ella, ya que muchos otros han intervenido sobre esto. Gracias por las críticas educadas! :)
Ravenstine
2

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).

Ed James
fuente
1
jshint sigue siendo una herramienta importante.
Raynos
En cuanto a la desambiguación de una declaración, ambos \ny ;\nson lo mismo
Raynos
2
@Raynos En realidad, he descubierto que JSLint tiende a ser un poco inútil con la complejidad de algunos de los códigos de marco pesado con los que a menudo trabajo. Además,; \ n y \ n no son iguales en todas las circunstancias , de lo contrario, nunca sería necesario el;.
Ed James
77
jslint es inútil, sin embargo, jshint es una herramienta diferente.
Raynos
0

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.

ovejas voladoras
fuente
0

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.

Delfín Supremo
fuente