javascript - two - ¿Hay peligros de inserción de punto y coma con operadores continuos en la siguiente línea?

multiline string javascript es6 (2)

Históricamente, me gusta romper expresiones para que el sesgo "está claramente incompleto" se muestre en la línea continua:

var something = foo + bar + baz(mumble);

Esta es una actitud que proviene del trabajo en idiomas que necesitan puntos y coma para terminar expresiones. La primera línea ya está obviamente incompleta debido a la falta de punto y coma, por lo que es mejor dejarle claro al lector que la segunda línea no está completa.

La alternativa sería:

var something = foo + bar + baz(mumble);

Eso no es tan bueno para mí. Ahora la única manera de decir eso baz(mumble); no es independiente (la sangría a un lado) es escanear los ojos hasta el final de la línea anterior. (Lo cual es presumiblemente largo, ya que necesitabas romperlo en primer lugar).

Pero en el bizarro JavaScript land , comencé a ver a las personas cambiar el código de las cosas que parecían desde la primera forma hasta la segunda y advertir sobre la "inserción automática de punto y coma". Sin duda provoca algunos comportamientos sorprendentes . En realidad, no quería ahondar en esa tangente en el momento en que puse "aprender qué es la inserción automática de punto y coma y si debería hacerlo también" en mi cola de tareas infinitas.

Cuando lo vi, me encontré casi seguro ... pero no seguro ... de que no hay ningún peligro en cómo lo uso. Parece que los problemas vendrían si hubiera dejado el + por accidente y escrito:

var something = foo + bar baz(mumble);

... luego JavaScript inserta un punto y coma después de foo + bar , aparentemente porque ambas líneas son independientes como expresiones completas. Tal vez deduje que aquellos otros programadores de JavaScript pensaron que sesgar el bit "claramente intencionalmente incompleto" hasta el final de la línea a continuar fue mejor, porque identificó la ubicación donde no estaba el punto y coma .

Sin embargo, si he establecido correctamente mi premisa, estoy diseñando mis líneas discontinuas de manera que las líneas resultantes sean "obviamente incompletas". Si ese no fuera el caso, entonces no consideraría mi camino como una ventaja en primer lugar.

¿Estoy en lo cierto, que mi manera no es un riesgo para las condiciones que describo de cómo uso las continuaciones de línea? ¿Hay algún error en la expresión "aparentemente incompleta" que se complete de manera sorprendente?

Para ofrecer un ejemplo de "completar de manera sorprendente", considere si + 1; Podría ser interpretado como solo positivo en una línea por sí mismo. Lo que parece que puede:

Pero jsfiddle devuelve 6 para esto:

var x = 3 + 2 + 1; alert(x)

Tal vez eso sea solo una peculiaridad en la consola, pero me hace preocuparme por mi interpretación de "está bien siempre y cuando la segunda línea no esté sola como una expresión completa" .

Comencé a ver a las personas cambiar el código de las cosas que parecían desde el primer formulario hasta el segundo, y advertir sobre la "inserción automática de punto y coma"

Eso es basura. Cuando tenga un operador (en cualquiera de las dos líneas), no habrá ASI; consulte ¿Cuáles son las reglas para la inserción automática de punto y coma (ASI) de JavaScript?

Dado que ambos estilos de colocación del operador funcionarán, ambos son aceptados comúnmente y se reducen a preferencias personales / de estilo. Ya nombraste algunos argumentos, una vez que hayas elegido manténlos para mantener la coherencia.

No hay nada "peligroso" en ninguno de los dos y, honestamente, no debería preocuparse por ASI. La gente se muerde por eso solo porque a) no les gustan los puntos y comas y esperan una inserción automática, pero la siguiente línea es una continuación sintácticamente válida o b) escriben literales de objetos / matrices después de una declaración de return al estilo de Allman.

Si toma alguna línea sintácticamente válida y la puntúa con saltos de línea, no se aplicará la inserción automática de punto y coma (excepto en el caso estrecho de return , throw y muy pocas otras declaraciones, que se enumeran a continuación). ASI solo ocurre cuando no hay absolutamente ninguna otra forma de interpretar el código. Ciertamente, hay una manera de interpretar su código multilínea como una sola declaración, porque es válido como una sola línea. En resumen, ASI es generalmente una herramienta de último recurso en el intento del analizador por comprender el programa.

Para citar ES5, se produce el primer caso de ASI detallado en la especificación ...

Cuando, cuando el programa se analiza de izquierda a derecha, se encuentra un token (llamado token ofensivo) que no está permitido por ninguna producción de la gramática ...

Pero ese caso se elimina de forma natural, porque tenías una línea gramaticalmente válida antes de inyectar una nueva línea en ella. Por lo tanto, este caso de ASI no puede aplicarse a su caso porque depende de un intervalo de código que no es sintácticamente válido sin punto y coma. No tienes eso aquí.

(Los otros dos casos tampoco se aplican; el segundo caso se aplica al final de un programa y el tercer caso se aplica a los operadores continue , break , return , throw y postfix ++ / -- ).

El problema común que tienen las personas con ASI ocurre cuando un autor tiene dos líneas que él espera que se mantengan separadas, pero esas dos líneas no causan problemas gramaticales cuando se entienden como una sola línea. Ese caso comienza con dos líneas y accidentalmente se convierten en una. Tus casos son lo inverso: comienzas con una línea; no se convierte accidentalmente en dos.