Explicación del salto de línea incorrecto de JSHint antes del error '+'

125

¿Alguien puede explicarme por qué JSHint se queja de lo siguiente,

window.location.href = String1
    + '#'
    + Sting2
    + '='
    + String3;

Con el error Bad line breaking before '+' error

Entiendo que este error se puede configurar con la laxbreak opción , que se describe como

Esta opción suprime la mayoría de las advertencias sobre saltos de línea posiblemente inseguros en su código. No suprime las advertencias sobre el estilo de codificación de primera coma. Para suprimirlos, debe usar laxcomma (ver más abajo).

Esta explicación es bastante breve y tengo curiosidad acerca de por qué romper líneas de esta manera se considera malo o laxo en primer lugar.

Tenga en cuenta que no estoy tratando de comenzar una guerra santa aquí, solo estoy buscando una respuesta objetiva sobre por qué la gente de JSHint piensa que esto es malo, si es solo una preferencia de estilo que están inyectando en su linter (pensé que JSLint era el linter obstinado), o si hay algo que puede salir mal en ciertos intérpretes cuando se rompe la línea de esta manera.

javascript jshint James McMahon
fuente
66
Creo que es solo un "mal estilo" según JSHint. Obtendrá el mismo efecto si usa comas iniciales. Para facilitar la lectura, al menos lo reescribiría con el + al final de la línea.
Iwan
28
Gorrón. Creo que este estilo es absolutamente el más legible para usar con cadenas de varias líneas, especialmente cuando se ve el código en una ventana estrecha.
Lambart
12
el uso de tokens que continúan con la instrucción ayuda a alinear las cosas y a expresar visualmente la continuación en la parte izquierda del bloque de código, que es donde uno esperaría encontrar los elementos estructurales, especialmente si escanea rápidamente. Definitivamente es viable y razonable y no, objetivamente, mal estilo. Sin embargo, hay un problema de integridad del código para hacer cumplir esta regla, lo cual es lamentable.
Adam Tolley
1
@AdamTolley Estoy completamente de acuerdo, y cuando pregunté sobre esto obtuve lo que parecía ser la confirmación de que se trataba de FUD. Fue puesto bajo escrutinio después del "metaefecto"; y ese escrutinio pareció confirmar que esto es viable y razonable.
HostileFork dice que no confíes en SE
2
Hoy en día ( JSHint 2.9.4 ) el mensaje de error es Salto de línea engañoso antes de '+'; Los lectores pueden interpretar esto como un límite de expresión.
RhinoDevel

Respuestas:

107

Es una guía de estilo para evitar afirmaciones que puedan estar sujetas a suposiciones sobre la inserción automática de punto y coma .

La idea es dejar en claro al final de una línea si la expresión termina allí o podría continuar en la siguiente línea.

Barney
fuente
66
Gracias por la respuesta, tener una justificación detrás del error hace que sea mucho más fácil para mí justificar los cambios para apaciguar a JSHint.
James McMahon
36
La inserción automática de punto y coma es un racional razonable para que este estilo se aplique. Pero cuando la expresión está entre paréntesis, la advertencia persiste. Y eso me pone triste.
Ben Hyde
23
segundo @BenHyde, y en general es más legible para los humanos cuando se hojea el código para liderar la línea con un +. Es más fácil para los ojos (y menos propenso a errores) seguir una sola columna a la izquierda que saltar al final de cada línea para ver si la siguiente línea la agregará. incluso la gramática es menos torpe: "La línea 118 agrega 117" versus "La línea 117 se agregará a la línea 118".
worc
9
Personalmente, odio agregar operadores (y comas) al final de las líneas porque lo paso rápidamente. Es más fácil para mí leer la lógica en declaraciones booleanas de varias líneas (&& o || al principio de una línea en lugar de al final), y puedo distinguir rápidamente las listas delimitadas por comas aparte de otras declaraciones de varias líneas comenzando con un coma. Gracias a Dios por laxbreak
aaaaaa
2
@Barney ¿Cómo concilias la preocupación por la inserción automática de punto y coma con las respuestas dadas a mi pregunta muy similar ? ¿Cuál es el riesgo justificable de este formato? Para mí tiene la ventaja de la capacidad de escaneo.
HostileFork dice que no confíes en SE
8

Jshint no marcará esto como un salto de línea incorrecto si usa el + antes del salto de línea en lugar de en la nueva línea. Al igual que:

window.location.href = String1 +
'#' +
Sting2 +
'=' +
String3;
asulaiman
fuente
10
Esto no responde la pregunta ni una pizca. ¿Por qué tantos votos positivos?
Lambart
44
Quizás, pero esta es una forma de solucionar este problema sin tener que cambiar la configuración de jshint.
asulaiman
44
Esto debería ser un comentario, ya que en realidad no responde la pregunta, pero proporciona información valiosa.
tomtomssi
3

No es una respuesta directa a la pregunta, pero para cualquiera que se encuentre con esto en Google (como lo hice yo) y desee mantener la regla pero corregir las advertencias, lo siguiente puede ser útil ...

Al usar Notepad ++ (por ejemplo, con el complemento JSLint), esto se puede solucionar mediante la siguiente búsqueda y reemplazo:

  • Encontrar que: (\r\n|\n|\r)( *)\+
  • Reemplazar con: (incluido el primer y último espacio) +$1$2 
  • Modo de búsqueda: expresión regular

(Solo se probó en Windows, pero la expresión regular también debería funcionar con las terminaciones de línea de Unix o Mac OS).

Para hacer una cosa similar para ||, &&, ==, !=, <=o >=en lugar de +, utilice la siguiente:

  • Encontrar que: (\r\n|\n|\r)( *)(\|\||&&|==|!=|<=|>=)
  • Reemplazar con: (incluido el primer y último espacio) $3$1 $2 
Steve Chambers
fuente
55
Útil, tal vez, para las personas que desean cambiar su formato. Pero no responde completamente a la pregunta (implícita): "Tengo curiosidad acerca de por qué romper líneas de esta manera se considera malo o laxo en primer lugar".
Lambart
Punto justo, he agregado una nota en la parte superior explicando por qué publiqué esto.
Steve Chambers