Wyjaśnienie nieprawidłowego łamania linii JSHint przed błędem „+”

125

Czy ktoś może mi wyjaśnić, dlaczego JSHint narzeka na następujące kwestie,

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

Z błędem Bad line breaking before '+' error

Rozumiem, że ten błąd można skonfigurować za pomocą laxbreak opcji , która jest opisana jako

Ta opcja pomija większość ostrzeżeń o potencjalnie niebezpiecznych podziałach wierszy w kodzie. Nie pomija ostrzeżeń o stylu kodowania zaczynającym się od przecinka. Aby je stłumić, musisz użyć laxcomma (patrz poniżej).

To wyjaśnienie jest dość zwięzłe i jestem ciekaw, dlaczego łamanie linii w ten sposób jest przede wszystkim uważane za złe lub luźne.

Pamiętaj, że nie próbuję tutaj rozpoczynać świętej wojny, po prostu szukam obiektywnej odpowiedzi na pytanie, dlaczego ludzie z JSHint myślą, że to jest złe, czy to tylko preferencja stylu, którą wstrzykują do swojego lintera (myślałem, że JSLint to uparty linter) lub jeśli jest coś, co może się nie udać niektórym tłumaczom podczas łamania linii w ten sposób.

javascript jshint James McMahon
źródło
6
Myślę, że to po prostu „zły styl” według JSHint. Ten sam efekt uzyskasz, jeśli użyjesz przecinków na początku. Dla czytelności przynajmniej przepisałbym to z + na końcu linii.
Iwan,
28
Porażka. Myślę, że ten styl jest absolutnie najbardziej czytelnym stylem używanym w przypadku ciągów wieloliniowych, zwłaszcza podczas przeglądania kodu w wąskim oknie.
Lambart
12
prowadzenie z tokenami, które kontynuują instrukcję, pomagają wyrównać rzeczy i wizualnie wyrazić kontynuację w lewej części bloku kodu, w którym można się spodziewać znalezienia elementów strukturalnych, zwłaszcza w przypadku szybkiego skanowania. Jest to zdecydowanie wykonalne i rozsądne, a obiektywnie nie jest to zły styl. Istnieje jednak problem z integralnością kodu przy egzekwowaniu tej reguły, co jest niefortunne.
Adam Tolley,
1
@AdamTolley Całkowicie się zgadzam, a kiedy o to zapytałem, otrzymałem coś, co wydawało się potwierdzeniem, że to FUD. Został poddany kontroli po „efekcie meta”; a analiza wydawała się potwierdzać, że jest to wykonalne i rozsądne.
HostileFork mówi, że nie ufaj SE
2
Obecnie ( JSHint 2.9.4 ) komunikat o błędzie to wprowadzający w błąd podział wiersza przed „+”; czytelnicy mogą zinterpretować to jako granicę wyrażenia.
RhinoDevel

Odpowiedzi:

107

Jest to przewodnik po stylu, aby uniknąć stwierdzeń, które mogą być podatne na założenia dotyczące automatycznego wstawiania średników .

Chodzi o to, aby na końcu linii było jasne, czy wyrażenie się tam kończy, czy może być kontynuowane w następnej linii.

Barney
źródło
6
Dziękuję za odpowiedź, uzasadnienie błędu znacznie ułatwia mi uzasadnienie wprowadzenia zmian w celu uspokojenia JSHint.
James McMahon
36
Automatyczne wstawianie średnika jest rozsądnym uzasadnieniem dla egzekwowania tego stylu. Ale jeśli wyrażenie znajduje się w jakimś nawiasie, ostrzeżenie nie zniknie. I to mnie zasmuca.
Ben Hyde,
23
second @BenHyde i ogólnie rzecz biorąc, jest bardziej czytelny dla człowieka, gdy przegląda kod, aby poprowadzić wiersz za pomocą +. łatwiejsze dla oczu (i mniej podatne na błędy) jest podążanie za pojedynczą kolumną po lewej stronie niż przeskakiwanie na koniec każdej linii, aby zobaczyć, czy zostanie dodany do następnej linii. nawet gramatyka jest mniej niezgrabna: „Linia 118 dołącza 117” w porównaniu z „Linia 117 zostanie dodana do linii 118”.
worc
9
Osobiście nienawidzę dodawania operatorów (i przecinków) na końcu linii, ponieważ przeskakuję obok nich. Łatwiej jest mi odczytać logikę w wielowierszowych instrukcjach boolowskich (&& lub || na początku wiersza zamiast na końcu) i mogę szybko odróżnić listy rozdzielane przecinkami od innych wielowierszowych instrukcji zaczynając je od przecinek. Dzięki Bogu za laxbreak
aaaaaa
2
@Barney Jak pogodzisz obawy dotyczące automatycznego wstawiania średnika z odpowiedziami udzielonymi na moje bardzo podobne pytanie ? Jakie jest uzasadnione ryzyko związane z tym formatem? Dla mnie ma to przewagę w skanowalności.
HostileFork mówi, że nie ufaj SE
8

Jshint nie oznaczy tego jako złego końca linii, jeśli użyjesz + przed podziałem linii, w przeciwieństwie do w nowej linii. Tak jak to:

window.location.href = String1 +
'#' +
Sting2 +
'=' +
String3;
asulaiman
źródło
10
To nie daje odpowiedzi na pytanie ani na jotę. Skąd tyle głosów pozytywnych?
Lambart
4
Być może, ale jest to jeden ze sposobów obejścia tego problemu bez konieczności zmiany ustawień jshint.
asulaiman,
4
Powinien to być komentarz, ponieważ tak naprawdę nie odpowiada na pytanie, ale dostarcza cennych informacji.
tomtomssi
3

Nie jest to bezpośrednia odpowiedź na to pytanie, ale dla każdego, kto natknie się na to z Google (tak jak ja), który chce zachować regułę, ale naprawić ostrzeżenia, przydatne mogą być poniższe wskazówki ...

Podczas korzystania z Notepad ++ (np. Z wtyczką JSLint) można to naprawić za pomocą następującego wyszukiwania i zamiany:

  • Znajdź co: (\r\n|\n|\r)( *)\+
  • Zamień na: (łącznie z pierwszą i ostatnią spacją) +$1$2 
  • Tryb wyszukiwania: wyrażenie regularne

(Testowane tylko w systemie Windows, ale wyrażenie regularne powinno również działać z zakończeniami linii w systemie Unix lub Mac OS).

Zrobić coś podobnego do ||, &&, ==, !=, <=lub >=zamiast +, użyj tego:

  • Znajdź co: (\r\n|\n|\r)( *)(\|\||&&|==|!=|<=|>=)
  • Zamień na: (łącznie z pierwszą i ostatnią spacją) $3$1 $2 
Steve Chambers
źródło
5
Być może przydatne dla osób, które chcą zmienić swoje formatowanie. Ale kompletnie nie daje odpowiedzi na (domniemane) pytanie: „Jestem ciekaw, dlaczego łamanie linii w ten sposób jest w pierwszej kolejności uważane za złe lub luźne”.
Lambart
Słuszna uwaga, dodałem notatkę u góry wyjaśniającą, dlaczego to opublikowałem.
Steve Chambers