Объяснение неправильного разрыва строки JSHint перед ошибкой '+'

125

Может кто-нибудь объяснить мне, почему JSHint жалуется на следующее:

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

С ошибкой, Bad line breaking before '+' error

Я понимаю, что эту ошибку можно настроить с помощью laxbreak параметра , который описывается как

Этот параметр подавляет большинство предупреждений о потенциально небезопасных разрывах строк в вашем коде. Он не подавляет предупреждения о стиле кодирования с запятой. Чтобы подавить их, вы должны использовать laxcomma (см. Ниже).

Это объяснение довольно краткое, и мне любопытно, почему такое прерывание линий считается плохим или слабым в первую очередь.

Имейте в виду, что я не пытаюсь начать здесь священную войну, я просто ищу объективный ответ о том, почему люди из JSHint думают, что это плохо, является ли это просто предпочтением стиля, которое они вводят в свой линтер (я думал, что JSLint был упрямый линтер), или если что-то может пойти не так с некоторыми интерпретаторами при таком разрыве строки.

javascript jshint Джеймс МакМахон
источник
6
Я считаю, что это просто «плохой стиль» согласно JSHint. Вы получите тот же эффект, если будете использовать запятые в начале. Для удобства чтения я бы хотя бы переписал его с + в конце строки.
Iwan
28
Облом. Я думаю, что этот стиль является наиболее читаемым для использования с многострочными строками, особенно при просмотре кода в узком окне.
Lambart
12
начало с токенами, которые продолжают оператор, помогают выровнять вещи и визуально выразить продолжение в левой части блока кода, где можно было бы ожидать найти структурные элементы, особенно при быстром сканировании. Это определенно жизнеспособно и разумно, и объективно неплохой стиль. Однако существует проблема целостности кода для применения этого правила, что вызывает сожаление.
Адам Толли
1
@AdamTolley: Я полностью согласен, и когда я спросил об этом, получил, казалось бы, подтверждение, что это FUD. После «метаэффекта» он был подвергнут тщательному изучению; и эта проверка, похоже, подтвердила, что это жизнеспособно и разумно.
HostileFork говорит, что не доверяйте SE
2
В настоящее время ( JSHint 2.9.4 ) сообщение об ошибке - вводящий в заблуждение разрыв строки перед
RhinoDevel

Ответы:

107

Это руководство по стилю, позволяющее избегать утверждений, которые могут быть связаны с предположениями об автоматической вставке точки с запятой .

Идея состоит в том, что к концу строки вы проясняете, заканчивается ли выражение на этом или может быть продолжено на следующей строке.

гулянка
источник
6
Спасибо за ответ, объяснение ошибки значительно облегчает мне обоснование внесения изменений, чтобы успокоить JSHint.
Джеймс МакМахон
36
Автоматическая вставка точки с запятой является разумным аргументом в пользу применения этого стиля. Но когда выражение заключено в круглые скобки, предупреждение сохраняется. И это меня огорчает.
Бен Хайд
23
второй @BenHyde, и в целом он более удобочитаем, когда бегло просматриваешь код, чтобы вести линию с расширением +. легче для глаз (и менее подвержено ошибкам) ​​следить за одним столбцом слева, чем переходить к дальнему концу каждой строки, чтобы увидеть, будет ли он добавлен следующей строкой. даже грамматика менее неуклюжая: «Строка 118 добавляет 117» против «Строка 117 будет добавлена ​​Строкой 118».
Worc
9
Лично я ненавижу добавлять операторы (и запятые) в конец строк, потому что я бегаю мимо них. Мне легче читать логику в многострочных логических операторах (&& или || в начале строки, а не в конце), и я могу быстро отличить списки, разделенные запятыми, от других многострочных операторов, начав их с запятая. Слава богу за laxbreak
aaaaaa
2
@Barney Как вы примирите озабоченность по поводу автоматической вставки точки с запятой с ответами на мой очень похожий вопрос ? Каков оправданный риск этого формата? Для меня это преимущество в возможности сканирования.
HostileFork говорит, что не доверяйте SE
8

Jshint не будет отмечать это как плохой разрыв строки, если вы используете + перед разрывом строки, а не в новой строке. Вот так:

window.location.href = String1 +
'#' +
Sting2 +
'=' +
String3;
asulaiman
источник
10
Это ни на йоту не отвечает на вопрос. Почему так много голосов за?
Lambart
4
Возможно, но это один из способов обойти эту проблему без изменения настроек jshint.
asulaiman
4
Это должен быть комментарий, поскольку он не отвечает на вопрос, но предоставляет ценную информацию.
tomtomssi 09
3

Не прямой ответ на вопрос, но для всех, кто сталкивается с этим в Google (как и я), кто хочет сохранить правило, но исправить предупреждения, может быть полезно следующее ...

При использовании Notepad ++ (например, с плагином JSLint) это можно исправить с помощью следующего поиска и замены:

  • Найти то, что: (\r\n|\n|\r)( *)\+
  • Заменить на: (включая первый и последний пробелы) +$1$2 
  • Режим поиска: регулярное выражение

(Проверено только в Windows, но регулярное выражение также должно работать с окончаниями строк в Unix или Mac OS.)

Для того, чтобы сделать подобную вещь для ||, &&, ==, !=, <=или >=вместо того , чтобы +использовать это:

  • Найти то, что: (\r\n|\n|\r)( *)(\|\||&&|==|!=|<=|>=)
  • Заменить на: (включая первый и последний пробелы) $3$1 $2 
Стив Чемберс
источник
5
Может быть полезно для людей, которые хотят изменить свое форматирование. Но он полностью не отвечает на (подразумеваемый) вопрос: «Мне любопытно, почему такое прерывание линий вообще считается плохим или слабым».
Lambart
Справедливо, добавили примечание вверху, объясняющее, почему я разместил это.
Стив Чемберс,