截断方法调用答案

【问题标题】：Truncating Method calls截断方法调用
【发布时间】：2010-09-14 18:27:23
【问题描述】：

这是一个主观问题，因为我想衡量我是否值得我抱怨我的同事做了一些我觉得完全可憎的事情。

问题是我的一群同事会截断方法调用以适应宽度。我们都使用可以处理大分辨率的宽屏笔记本电脑（我的是 1920x1200），在调试和阅读代码时，我发现阅读单行方法调用比阅读多行调用要容易得多。

这是一个方法的例子（我喜欢它）：

IReallyLongInterfaceName instanceOfInterfaceName = OurContainer.retrieveClass(IReallyLongInterfaceName.class, param1, param2, param3);

（我也讨厌很长的接口/类名：）

这似乎在 StackOverflow 上渲染得不好，但我想你们中的大多数人都知道我的意思。无论如何，其他一些开发人员会执行以下操作。

IReallyLongInterfaceName instanceOfInterfaceName = OurContainer.retrieveClass(IReallyLongInterfaceName.class, 
                                                                              param1, 
                                                                              param2, 
                                                                              param3);

在一天结束时哪一个更容易阅读，我要求他们使用两者中的第一个（因为它是我们标准的一部分）是不合理的？

【问题讨论】：

听起来好像你的人数超过了。我更喜欢选项 2。然后我仍然瞄准 80 列代码。
看起来确实是这样，我可能不会将任何东西标记为答案，但有趣的是，看看我实际上是多么的寡不敌众:(

标签： java code-formatting

【解决方案1】：

我发现第一个示例总体上更具可读性，但如果它超过某个预定义的限制（对我来说是 120 个字符），我会换行：

IReallyLongInterfaceName instanceOfInterfaceName =
        OurContainer.retrieveClass(IReallyLongInterfaceName.class,
                                   param1, param2, param3);

【讨论】：

这得到了我的投票，几乎是正确的。那么真正的问题就变成了，你在什么时候强制换行。在 80 个字符的限制处，在运算符处，以及函数开头的括号等处。在所有这些中，我使用的运算符中断最多，就像这个答案。

【解决方案2】：

也许你应该在你的标准构建过程中使用某种 checkstyle 插件来检查这种东西？如果您已与您的同事就该标准达成一致，要求他们遵守该标准似乎是合理的。

我个人认为这两个选项中的第二个更具可读性，但这只是因为我没有宽屏显示器；）

【讨论】：

【解决方案3】：

如果它在公司编码标准中明确指出方法一是正确的方法，那么无论如何都要抱怨他们，毕竟他们没有遵守公司标准。如果没有明确说明，那么我想现在是将其纳入标准的好时机。不过要注意的一件事是，如果您使用的是具有自动格式化功能的 IDE，它可能会在运行时自行将方法重新格式化为样式 2。因此，即使每个人都在按照样式 1 写作，但当他们完成时，它最终可能不会是那样。

和 Phil 一样，我发现方法 2 的可读性更高，因为您可以看到您需要看到的所有内容，而无需侧身滚动 :)

【讨论】：

【解决方案4】：

我更喜欢第二个例子。即使您可能有宽屏笔记本电脑，但您可能并不总是全屏显示 Windows，或者在您的 IDE 中，您可能在主要编码区域周围有很多其他面板，这些面板会减少显示代码的可用宽度。

如果不滚动就无法容纳行，那么垂直滚动比水平滚动更可取。由于我们是从左到右阅读的，因此水平滚动意味着一直向后和向前移动。

我更喜欢每行一个参数而不是 Avi 的建议，这对我来说是任意的。如果将参数分散在多行但每行有多个参数，则在阅读代码时会更难找到特定参数。

【讨论】：

在大多数 diff'ing 工具中，宽线也是一个#@$#，这会让代码审查变得痛苦。

【解决方案5】：

我也更喜欢选项 #2。问题不仅在于它在屏幕上的外观（如果我有 1920 个水平像素，我会有更多停靠的窗口），而是它在我需要打印和阅读时的外观。大多数 IDE 会打印出很长的行，而作者为了提高易读性而打断的行会打印得很好。

另一点是一般的易读性。杂志和报纸分栏印刷是有原因的——通常，更短的行和更好的布局/格式可以提高文本（尤其是屏幕上的文本）的可读性。

我认为 80 可能过于随意，但我使用的是 10pt Consolas，而且我似乎能够在标准 8.5" 打印页面上每行获得大约 100 个字符。

现在说到底，这是一场圣战。也许没有把花括号放在哪里那么糟糕，但它就在那里。我已经给了你我的偏好，但真正的问题又回到了你身上：你公司的标准是什么？在我看来，他们已经对选项 2 进行了标准化，这意味着为了团队的利益，您可能应该适应它们。

【讨论】：

【解决方案6】：

我更喜欢选项 2，但对于变量名不明显的参数，可以选择使用 cmets。当您有一个要求一堆参数的函数调用时，审阅者可能很难判断代码在做什么。

所以，如果给定函数的参数超过 3 个，我通常会这样编码：

applyEncryptionParameters(key,
                          certificate,
                          0, // strength - set to 0 to accept default for platform
                          algorithm);

【讨论】：