Spiegazione dell'interruzione della linea Bad di JSHint prima dell'errore '+'


125

Qualcuno può spiegarmi perché JSHint si lamenta di quanto segue,

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

Con l'errore, Bad line breaking before '+' error

Comprendo che questo errore può essere configurato con l' laxbreak opzione , che è descritta come

Questa opzione elimina la maggior parte degli avvisi relativi a interruzioni di linea potenzialmente non sicure nel codice. Non elimina gli avvisi sullo stile di codifica virgola-first. Per sopprimere quelli devi usare il lasscomma (vedi sotto).

Questa spiegazione è piuttosto concisa e sono curioso di sapere perché spezzare le linee in questo modo sia considerato cattivo o rilassato in primo luogo.

Tieni presente che non sto cercando di iniziare una guerra santa qui, sto solo cercando una risposta obiettiva sul perché le persone di JSHint pensano che questo sia negativo, sia che si tratti solo di una preferenza di stile che stanno iniettando nella loro linter (pensavo che JSLint fosse il linter supponente), o se c'è qualcosa che può andare storto su alcuni interpreti quando si interrompe la linea in questo modo.


6
Penso che sia solo "cattivo stile" secondo JSHint. Avresti lo stesso effetto se usi le virgole principali. Per leggibilità, lo riscriverei almeno con il + alla fine della riga.
Iwan,

28
Bummer. Penso che questo stile sia assolutamente lo stile più leggibile da usare con le stringhe multilinea, specialmente quando si visualizza il codice in una finestra stretta.
Lambart,

12
condurre con token che continuano l'affermazione aiuta ad allineare le cose ed esprimere visivamente la continuazione nella parte sinistra del blocco di codice, che è dove ci si aspetterebbe di trovare gli elementi strutturali, specialmente se la scansione è veloce. È decisamente praticabile e ragionevole e non, oggettivamente, cattivo stile. Vi è, tuttavia, un problema di integrità del codice per l'applicazione di questa regola, il che è sfortunato.
Adam Tolley,

1
@AdamTolley Sono completamente d'accordo, e quando ho chiesto a questo proposito ho ottenuto quella che sembrava essere la conferma che questo era FUD. È stato messo sotto esame dopo "meta-effetto"; e quel controllo sembrava confermare che ciò era fattibile e ragionevole.
HostileFork afferma di non fidarsi di SE

2
Al giorno d'oggi ( JSHint 2.9.4 ) il messaggio di errore è un'interruzione di riga fuorviante prima di '+'; i lettori possono interpretare questo come un limite di espressione.
RhinoDevel,

Risposte:


107

È una guida di stile per evitare dichiarazioni che potrebbero essere soggette a ipotesi sull'inserimento automatico di punti e virgola .

L'idea è che si chiarisca alla fine di una riga se l'espressione finisce lì o si può continuare sulla riga successiva.


6
Grazie per la risposta, avere una logica dietro l'errore rende molto più facile per me giustificare apportare le modifiche per placare JSHint.
James McMahon,

36
L'inserimento automatico di punti e virgola è un ragionevole motivo per applicare questo stile. Ma quando l'espressione è racchiusa tra parentesi l'avvertimento persiste. E questo mi rende triste.
Ben Hyde,

23
secondo @BenHyde, e in generale è più leggibile dall'uomo quando si scorre il codice per condurre la linea con a +. è più facile per gli occhi (e meno incline all'errore) seguire una singola colonna a sinistra che saltare all'estremità di ogni riga per vedere se verrà aggiunta dalla riga successiva. anche la grammatica è meno goffa: "La riga 118 aggiunge 117" rispetto a "La riga 117 verrà aggiunta dalla riga 118."
worc,

9
Personalmente, odio aggiungere operatori (e virgole) alla fine delle righe perché lo sfoglio. È più facile per me leggere la logica in istruzioni booleane su più righe (&& o || all'inizio di una riga anziché alla fine) e posso distinguere rapidamente gli elenchi delimitati da virgole a parte le altre istruzioni a più righe avviandole con un virgola. Grazie a dio per laxbreak
aaaaaa,

2
@Barney Come conciliare la preoccupazione per l'inserimento automatico del punto e virgola con le risposte fornite alla mia domanda molto simile ? Qual è il rischio giustificabile di questo formato? Per me ha il vantaggio della scansionabilità.
HostileFork afferma di non fidarsi di SE

8

Jshint non lo segnalerà come una brutta interruzione di linea se si utilizza il + prima dell'interruzione di linea anziché nella nuova riga. Così:

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

10
Questo non risponde alla domanda nemmeno una iota. Perché così tanti voti positivi?
Lambart,

4
Forse, ma questo è un modo per aggirare questo problema senza dover modificare le impostazioni di jshint.
Asulaiman,

4
Questo dovrebbe essere un commento poiché non risponde realmente alla domanda ma fornisce informazioni preziose.
tomtomssi,

3

Non è una risposta diretta alla domanda, ma per chiunque si imbatta in Google (come ho fatto io) che desidera mantenere la regola ma correggere gli avvisi, potrebbe essere utile quanto segue ...

Quando si utilizza Notepad ++ (ad esempio con il plugin JSLint), questo può essere risolto usando la seguente ricerca e sostituzione:

  • Trovare cosa: (\r\n|\n|\r)( *)\+
  • Sostituisci con: (incluso il primo e l'ultimo spazio) +$1$2 
  • Modalità di ricerca: espressione regolare

(Testato solo su Windows ma il regex dovrebbe funzionare anche con terminazioni di linea Unix o Mac OS.)

Per fare una cosa simile per ||, &&, ==, !=, <=o >=al posto di +, utilizzare questo:

  • Trovare cosa: (\r\n|\n|\r)( *)(\|\||&&|==|!=|<=|>=)
  • Sostituisci con: (incluso il primo e l'ultimo spazio) $3$1 $2 

5
Utile, forse, per le persone che vogliono cambiare la loro formattazione. Ma non riesce completamente a rispondere alla domanda (implicita): "Sono curioso di sapere perché spezzare le linee in questo modo è considerato cattivo o rilassato in primo luogo".
Lambart,

Punto giusto, ho aggiunto una nota in alto che spiega perché l'ho pubblicato.
Steve Chambers,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.