Explication du mauvais saut de ligne de JSHint avant l'erreur '+'

125

Quelqu'un peut-il m'expliquer pourquoi JSHint se plaint de ce qui suit,

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

Avec l'erreur, Bad line breaking before '+' error

Je comprends que cette erreur peut être configurée avec l' laxbreak option , qui est décrite comme

Cette option supprime la plupart des avertissements concernant les sauts de ligne potentiellement dangereux dans votre code. Il ne supprime pas les avertissements concernant le style de codage par virgule. Pour supprimer ceux-ci, vous devez utiliser laxcomma (voir ci-dessous).

Cette explication est assez laconique et je suis curieux de savoir pourquoi briser les lignes de cette façon est considéré comme mauvais ou laxiste en premier lieu.

Gardez à l'esprit que je n'essaye pas de lancer une guerre sainte ici, je cherche juste une réponse objective sur les raisons pour lesquelles les gens de JSHint pensent que c'est mauvais, que ce soit juste une préférence de style qu'ils injectent dans leur linter (je pensais que JSLint était le linter opiniâtre), ou s'il y a quelque chose qui peut mal tourner sur certains interprètes lors de la rupture de ligne de cette façon.

James McMahon
la source
6
Je pense que c'est juste du "mauvais style" selon JSHint. Vous obtiendrez le même effet si vous utilisez des virgules de début. Pour plus de lisibilité, je le réécrirais au moins avec le + à la fin de la ligne.
Iwan
28
Bummer. Je pense que ce style est absolument le style le plus lisible à utiliser avec des chaînes multi-lignes, en particulier lors de l'affichage du code dans une fenêtre étroite.
Lambart
12
la direction avec des jetons qui continuent l'instruction aide à aligner les choses et à exprimer visuellement la continuation dans la partie gauche du bloc de code, où l'on s'attendrait à trouver les éléments structurels, surtout si l'analyse est rapide. C'est définitivement viable et raisonnable et pas, objectivement, un mauvais style. Il existe cependant un problème d'intégrité du code pour l'application de cette règle, ce qui est regrettable.
Adam Tolley
1
@AdamTolley Je suis tout à fait d'accord, et quand j'ai posé des questions à ce sujet, j'ai obtenu ce qui semblait être la confirmation qu'il s'agissait de FUD. Il a été mis sous contrôle après "méta-effet"; et cet examen semble confirmer que cela est viable et raisonnable.
HostileFork dit de ne pas faire confiance à SE
2
De nos jours ( JSHint 2.9.4 ) le message d'erreur est un saut de ligne
RhinoDevel

Réponses:

107

C'est un guide de style pour éviter les instructions qui pourraient être sujettes à des hypothèses sur l'insertion automatique de points-virgules .

L'idée est que vous indiquez clairement à la fin d'une ligne si l'expression se termine là ou peut être poursuivie sur la ligne suivante.

Barney
la source
6
Merci pour la réponse, avoir une justification derrière l'erreur me permet de justifier beaucoup plus facilement les modifications pour apaiser JSHint.
James McMahon
36
L'insertion automatique de points-virgules est un rationnel raisonnable pour que ce style soit appliqué. Mais lorsque l'expression est entre parenthèses, l'avertissement persiste. Et cela me rend triste.
Ben Hyde
23
deuxième @BenHyde, et en général, il est plus lisible par l'homme lorsque vous parcourez le code pour mener la ligne avec un +. il est plus facile pour les yeux (et moins sujet aux erreurs) de suivre une seule colonne à gauche que de sauter à l'extrémité de chaque ligne pour voir si elle va être ajoutée par la ligne suivante. même la grammaire est moins maladroite: "La ligne 118 ajoute 117" contre "La ligne 117 va être ajoutée par la ligne 118."
worc
9
Personnellement, je déteste ajouter des opérateurs (et des virgules) à la fin des lignes parce que je les survole. Il m'est plus facile de lire la logique dans les instructions booléennes sur plusieurs lignes (&& ou || au début d'une ligne plutôt qu'à la fin), et je peux rapidement distinguer les listes délimitées par des virgules des autres instructions sur plusieurs lignes en les commençant par un virgule. Merci Dieu pour laxbreak
aaaaaa
2
@Barney Comment conciliez-vous le souci de l'insertion automatique de points-virgules avec les réponses données à ma question très similaire ? Quel est le risque justifiable de ce format? Pour moi, il a l'avantage de la numérisation.
HostileFork dit de ne pas faire confiance à SE
8

Jshint ne marquera pas cela comme un mauvais saut de ligne si vous utilisez le + avant le saut de ligne plutôt que dans la nouvelle ligne. Ainsi:

window.location.href = String1 +
'#' +
Sting2 +
'=' +
String3;
asulaiman
la source
10
Cela ne répond même pas à la question d'un iota. Pourquoi tant de votes positifs?
Lambart
4
Peut-être, mais c'est une façon de contourner ce problème sans avoir à modifier vos paramètres jshint.
asulaiman
4
Cela devrait être un commentaire car il ne répond pas vraiment à la question mais fournit des informations précieuses.
tomtomssi
3

Ce n'est pas une réponse directe à la question, mais pour quiconque rencontre cela de Google (comme je l'ai fait) qui souhaite garder la règle mais corriger les avertissements, ce qui suit peut être utile ...

Lorsque vous utilisez Notepad ++ (par exemple avec le plugin JSLint), cela peut être corrigé en utilisant la recherche et le remplacement suivants:

  • Trouver quoi: (\r\n|\n|\r)( *)\+
  • Remplacer par: (y compris le premier et le dernier espace) +$1$2 
  • Mode de recherche: expression régulière

(Uniquement testé sur Windows, mais l'expression régulière devrait également fonctionner avec les fins de ligne Unix ou Mac OS.)

Pour faire une chose semblable pour ||, &&, ==, !=, <=ou au >=lieu de +, utilisez ceci:

  • Trouver quoi: (\r\n|\n|\r)( *)(\|\||&&|==|!=|<=|>=)
  • Remplacer par: (y compris le premier et le dernier espace) $3$1 $2 
Steve Chambers
la source
5
Utile, peut-être, pour les personnes qui souhaitent modifier leur mise en forme. Mais cela échoue complètement à répondre à la question (implicite): "Je suis curieux de savoir pourquoi briser les lignes de cette façon est considéré comme mauvais ou laxiste en premier lieu."
Lambart
Bon point, j'ai ajouté une note en haut expliquant pourquoi j'ai posté cela.
Steve Chambers