问题标签 [code-readability]

I recently discovered that our company has a set of coding guidelines (hidden away in a document management system where no one can find it). It generally seems pretty sensible, and keeps away from the usual religious wars about where to put '{'s and whether to use hard tabs. However, it does suggest that "lines SHOULD NOT contain embedded multiple spaces". By which it means don't do this sort of thing:

Or this:

Or this:

The justification for this is that changes to one line often require every line to be edited. That makes it more effort to change, and harder to understand diffs.

I'm torn. On the one hand, lining up like this can make repetitive code much easier to read. On the other hand, it does make diffs harder to read.

What's your view on this?

在使用诸如 System.Data.Odbc 或 System.Data.OracleClient 之类的命名空间时，各种数据读取器方法通常需要为函数提供与列对应的整数（例如OracleDataReader.GetInt32）。

我的问题是，使用这些函数的最佳方法是什么，以使代码具有相当的自我记录性。现在，在我看来，有三个选择，即：

这些技术中的每一种似乎都有自己的优点和缺点，我很想知道其他人的想法，或者是否有更好的方法来做到这一点。

最终，代码（最终）编译成 CPU 的指令。然而，代码（以我的拙见）是供人类阅读、更新和交互的。这使我得出以下观察结果：

其他工程师无法阅读的代码，即使它是功能性的，也是糟糕的代码。

考虑到这一点，这个程序员可以做些什么来使代码更容易被人类阅读？

• 命名约定？（乔尔对此有很多话要说）

• 代码结构/布局？（拜托，看在上帝的份上，不要卷入{位置辩论）

• 措辞？（是否可以编写看起来更像英语的代码）

除了Joel 的文章之外，还有其他好的文章吗？

如果您在您选择的 IDE 中启用“查看右边距”，它可能会默认为 80 个字符。我倾向于将其更改为 120，除了这是我几年前所在公司的标准之外，没有其他公司告诉我这样做不同。

我的问题是，是否有任何研究实际上表明 80 个字符是代码可读性的最佳最大宽度，或者这个值只是“它一直都是这样”并且没有人真正知道为什么会这样？而且，一行代码的宽度是否应该成为您的编码标准的一部分？

考虑这一行：

显然这条线是一个潜在的错误，属性可能是null，我们会得到一个NullPointerException. 因此，我们需要将其重构为以下两种选择之一：

第一个选项：

第二种选择：

第一个选项阅读起来很尴尬，但更简洁，而第二个选项意图明确，但冗长。

就可读性而言，您更喜欢哪个选项？

假设您正在制作一个博客软件，并且想要显示一个条目获得的评论数量。你可以这样做：

这可能会导致：

但是，如果一个条目只有 1 条评论，我希望该行显示“评论”而不是“评论”。并且 in-lineif/else丑陋且重复。

处理这个问题的最佳方法是什么？

在一个变量可能有两个不同的值的情况下，如果它是一个，你会做某事，如果是另一个，你会做些什么：

或者你会这样做：

为了清楚起见，在读者不一定能说他们做同样的事情的情况下（但 else if 做了一个“不必要的”表达）？那你会怎么做？谢谢！

编辑：对于这样的事情实际上有更多不同的选项：三元运算符、if-else、if-elseif、if-elseif-else、-if-else(with assert)、switch。每个人都有自己的位置，但很难决定..

我遇到了一篇讨论“代码钦佩”问题的文章。基本上，作者谈到了开发人员应该如何对他们编写的代码持怀疑态度。我们如何过度“欣赏”我们的代码，将我们的自我附在它上面，使我们更容易受到可能摆在我们面前的错误和其他不幸的影响。

你怎么看待这个问题？您是否有更多关于如何避免/更加注意这个问题的提示？

我一直在研究 Lucene 2.9 之间的区别，特别是重做令牌流 API，我觉得它与旧的相比特别难看，如果你重用所说的令牌，只需返回一个新的或用值重新填充给定的值。

我没有进行任何分析，但似乎使用 MAP 存储属性效率不高，创建一个新的值类型保存值等会更容易。TokenStream 和 Attribute 的东西看起来像对象池，这几乎不需要这些天用于简单的值类型，例如文本标记。

我经常发现自己有一个Option[T]for 某种类型T，并希望根据某个值来测试该选项的值。例如：

下面的代码是等价的，去掉了测试选项值是否存在的要求

然而，这对我来说似乎不太可读。其他可能性是：

但我不认为这些清楚地表达了意图，这会更好：

有没有人有更好的方法来做这个测试？