好吧 是否认为这是不良做法？

IMO，它的可读性较差。我讨厌必须向右滚动，然后向左滚动，向右滚动，向左滚动等等。它使编码更加痛苦，有时使我感到困惑。

例如，无论何时我编码长字符串，我都将执行以下操作...

bigLongSqlStatement = "select * from sometable st inner join anothertable at" +
"on st.id = at.id" +
"and so on..." +
"and so on..." +
"and so on..."

是的，实际上的确如此，无论从字面意义上还是从一般意义上来说都是如此。

我喜欢并排进行代码比较，而太宽的行则使这变得更加困难：

诸如Scala之类的带有三引号字符串的语言使您可以从多行构造一个字符串，而无需花费运行时间，引人注目的引号和将字符串的各个部分连接在一起的加号（如您的示例所示）。

是的，我认为每行80个字符是合理且常用的。

对我来说，这是一个非常重要的问题！我已经在13英寸笔记本电脑上工作了7个月，同事们拥有24英寸台式显示器，但我发现自己花了很多时间来缩短生产线，以使可读性提高。

在很多情况下，80列有点小（除非您在使用vi的唯一终端上工作；除非），但超过150列太多（请参阅下文）。

这是纯粹的“可读性”问题。

现在，对于“良好实践”部分，我经常发现这样的长行存在缺陷，例如，某些部分应从临时变量中提取或重复，例如（ObjectiveC，iPhone编程中的常见代码段） ：

CGPoint point = CGPointMake(someOtherView.frame.origin.x + someOtherView.frame.size.width, someOtherView.frame.origin.x + someOtherView.frame.size.height);

请注意，在处理3维向量或矩阵时，这甚至会变得更加讨厌。

重写示例：

CGRect frame = someOtherView.frame;
CGPoint origin = frame.origin;
CGSize size = frame.size;
CGPoint point = CGPointMake(origin.x + size.width, origin.x + size.height);

现在，它可以安装在较小的屏幕上，更易于使用IDE进行调试或对标准输出进行一些写入，甚至可能更快，具体取决于方法/属性调用的成本。当然这有点强迫，大多数现实世界中的例子要复杂得多。

不总是。

只是添加一个替代视图，当我阅读代码时，我常常可以了解代码行在做什么，而不必阅读整个行。如果我可以读取方法名称，但方法参数从屏幕上溢出，通常我不会大惊小怪，因为仅从方法名称就可以看出那行代码的意图。如果屏幕上溅出了几行代码，那么对于更紧凑的代码而言，值得的是偶尔需要（在那里的重要单词）水平滚动的权衡是值得的。有时我会发现多行单语句代码会分散注意力，因为我必须在思维上拼凑哪些代码与哪个语句一起使用。

通常，水平溢出的代码行的左半边是重要位（可见），右半边是次重要位（屏幕外），所以对我来说，这可以提高可读性，因为我可以向下看代码，主要是看到每行中的重要位，而不是从太长的行中占据不太重要的代码位，而在随后的行中占据了视觉上重要的左侧空间。

说了这么多，我当然不想经常水平滚动，但是在这些宽屏显示器时代，我发现这不再是一个问题。

是的，它确实。

顺带一提。如果您使用的语言包含多行字符串（几乎所有脚本语言都包含它们）并且包含较长的SQL，则使用一致的SQL格式设置规则将SQL放入多行字符串中确实可以提高可读性。有关我使用的格式设置样式，请参见http://bentilly.blogspot.com/2011/02/sql-formatting-style.html。

不，不是。

我有一位编辑。它不仅具有换行符，而且具有换行符缩进，这会导致（如果屏幕显示宽度为100个字符）

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

出现为

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
    labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco 
    laboris nisi ut aliquip ex ea commodo consequat.

或将任何缩进级别设置为当前语言的默认语言。

比我的屏幕还要宽的行永远不会使代码的可读性比手动换行缩进的代码低。

编辑：哦，我知道这个答案将不受欢迎:)

当然是。报纸和杂志使用专栏是有原因的。可读性是一个重要因素。阅读时，我们的眼睛向下扫描时左右移动比较少。效果是让我们的眼睛快速浏览正在阅读的内容。

即使在屏幕上可见，宽列也会迫使我们的眼睛快速来回扫描。进行回扫时，我们实际上并没有任何了解。这将大大减慢阅读和理解的速度。效果类似于旧的机械打印机。这些通常需要在回车后插入几个空字符，以留出时间使回车或打印头重新定位到下一行。

另外，垂直布局通常以一种方式来阐明行中内容的分组。这通常仅应适用于复合逻辑条件。长公式可以更好地构造为一系列语句。（优化程序将解决所有额外的开销，并且某些优化程序将放弃复杂的公式或在复杂的公式上效果不佳。）

带有多个需要大行的点的标识符表示应纠正的编码技术。

鼠标滚轮可以轻松快速地垂直滚动...相比之下，水平滚动太昂贵了。

避免水平滚动。

〜Windows用户体验交互准则第112页

是。

英国人从左到右阅读，导致不断滚动=非生产性

因此，我总是在IDE中启用带有视觉线条标志的自动换行。