JSHint '+' 错误前的坏换行说明答案

【问题标题】：Explanation of JSHint's Bad line breaking before '+' errorJSHint '+' 错误前的坏换行说明
【发布时间】：2013-02-14 22:49:42
【问题描述】：

有人可以向我解释为什么 JSHint 抱怨以下内容，

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

出现错误，Bad line breaking before '+' error

我明白这个错误可以用laxbreakoption配置，描述为

此选项会抑制大多数有关代码中可能不安全的换行符的警告。它不会抑制有关逗号优先编码样式的警告。要抑制那些你必须使用 laxcomma（见下文）。

这个解释非常简洁，我很好奇为什么以这种方式断线首先被认为是不好的或松懈的。

请记住，我并不是想在这里发动一场圣战，我只是在寻找一个客观的答案，说明为什么 JSHint 人认为这很糟糕，是否只是他们注入到他们的 linter 中的一种风格偏好（我认为 JSLint 是固执己见的 linter），或者如果以这种方式换行时某些解释器可能会出错。

【问题讨论】：

我认为这只是 JSHint 的“坏风格”。如果您使用前导逗号，您将获得相同的效果。为了可读性，我至少会在行尾用 + 重写它。
无赖。我认为这种风格绝对是与多行字符串一起使用的最易读的风格，尤其是在窄窗口中查看代码时。
以继续语句的标记开头有助于对齐事物并在代码块的左侧部分直观地表达延续，这是人们期望找到结构元素的地方，尤其是在快速扫描的情况下。这绝对是可行和合理的，而且客观上不是糟糕的风格。但是，执行此规则存在代码完整性问题，这很不幸。
@AdamTolley 我完全同意，when I asked about this 得到了似乎是 FUD 的确认。在“元效应”之后受到审查；审查似乎证实了这是可行和合理的。
现在 (JSHint 2.9.4) 错误消息是 '+' 之前的误导性换行符；读者可能会将其解释为表达式边界。

【解决方案1】：

这是一个风格指南，以避免可能容易受到关于automatic semicolon insertion的假设的陈述。

这个想法是，您可以在一行的末尾明确表达式是在此处结束还是可以在下一行继续。

【讨论】：

感谢您的回答，错误背后的理由让我更容易证明做出更改以安抚 JSHint。
自动分号插入是强制执行这种样式的合理理由。但是当表达式在某个括号内时，警告仍然存在。而且，这让我很难过。
第二个@BenHyde，一般来说，在浏览代码以使用+ 引导时，它更易于阅读。跟随左侧的单列比跳到每行的远端以查看它是否会被下一行附加在眼睛上更容易（并且不容易出错）。甚至语法也不那么笨拙：“第 118 行追加 117”与“第 117 行将被第 118 行追加。”
就个人而言，我讨厌将运算符（和逗号）附加到行尾，因为我略过它。我更容易阅读多行布尔语句中的逻辑（&& 或 || 在行首而不是在行尾），并且我可以通过以逗号分隔的列表与其他多行语句快速区分逗号。感谢上帝的松懈
@Barney 您如何协调对自动分号插入的担忧与given to my very similar question 的答案？这种格式的合理风险是什么？对我来说，它在可扫描性方面具有优势。

【解决方案2】：

如果您在换行符之前而不是在新行中使用 +，Jshint 不会将此标记为错误的换行符。像这样：

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

【讨论】：

【解决方案3】：

不是对问题的直接回答，但对于希望保留规则但修复警告的谷歌搜索（就像我一样）遇到此问题的任何人，以下内容可能有用...

当使用 Notepad++（例如使用 JSLint 插件）时，可以使用以下搜索和替换来修复：

（仅在 Windows 上测试，但正则表达式也应该适用于 Unix 或 Mac OS 行结尾。）

要对||、&&、==、!=、<= 或 >= 做类似的事情，而不是 +，请使用：

【讨论】：