带注释的简短代码与无注释的较长且易于理解的代码-哪个是首选？

有时可以用两种方式编写算法：

• 一种简短的幻想方式；要么
• 更长的，易于理解的方式。

例如，这是一种将字符串复制source到destC中的更长，更简单的方法：

*dest = *source;
while (*source != '\0') {
    source++;
    dest++;
    *dest = *source;
} (true);

这是一种简短的幻想方式。

// Copy string source to dest
while (*dest++ = *source++);

我一直听到并读过，应该避免使用花哨的代码，我倾向于同意。但是，如果我们考虑到评论该怎么办？假定像上面的示例一样，我们有一个未注释的，较长的并且据说更易于理解的代码，以及一个注释良好的，简短的，精美的代码？非花哨的代码还是首选吗？

编辑：许多人对变量名发表了评论，所以我修改了示例代码，以免在优先选择其他变量时使它成为一个因素。我试图在第一个示例中删除双重分配，但这只会使代码的可读性降低。

也许这不是最好的示例，因为许多人发现“花哨的”代码比较长的代码更具可读性和可理解性。这个想法是要有一个更长的代码，比一个简短但复杂的代码更容易理解。

EDIT2：这是我从SO获得的一个新例子：

评论版本：

//direct formula for xoring all numbers from 1 to N
int Sum = (N & (N % 2 ? 0 : ~0) | ( ((N & 2)>>1) ^ (N & 1) ) );

非注释长版：

int Sum = 0;
for (int i = 1; i < N; ++i)
{
   Sum ^= i; //or Sum = Sum ^ i;
}

我通常更喜欢将精美代码提取到自己的方法中。

它的方法名称应该是使事情变得清晰所需的全部内容，而不是注释花哨的代码。

char *copy_string(char *s, const char *t) {    
    while (*s++ = *t++); 
    return s;
}

我全都支持更长的版本。短代码版本的问题，除了某些程序员更难以阅读之外，还在于大多数情况下，仅通过查看代码就很难发现错误。

我有一个真实的例子。在我们的产品中，我们具有以下代码片段：

if (++someCounter < MAX_VALUE) {
    // Do something that has to be done only MAX_VALUE times
}

乍一看，这段代码看起来完全合理，但是经过很长一段时间后，该计数器溢出并破坏了条件（在现实生活中，我们使用OOM粉碎了客户的生产系统）。这段代码不太“复杂”，但很明显，它可以执行应做的事情：

if (someCounter < MAX_VALUE) {
    ++someCounter;
    // Do whatever it is we came here for
}

您可能会说，编写此代码的开发人员还不够好（这是不对的，他是一个非常聪明的人），但是我认为，如果您的编码技术要求您成为超级傻瓜编程高手，为了使您的代码正确，您做错了什么。为您着想，以及您之后必须维护此代码的任何人（他们可能不如您那样聪明），您的代码应尽可能简单。

所以-我都是为了简单明了。

编辑：哦，关于评论-没关系。无论如何，许多人不会阅读注释（http://www.javaspecialists.co.za/archive/Issue039.html），而那些不加注释就无法理解您的代码的人，对他们的理解将不够好，以至于他们可以维护它。目的是帮助人们看到某些代码是“正确的”，注释对此无济于事。

我通常希望使用更长的版本。我想到两个主要原因：

• 更多的人可能会更轻松地理解它（假设它不是此字符串副本之类的“标准”示例）。
• 可以在单个语句上设置断点，并通过调试器逐步执行。

为了两全其美，请将代码包装在一个函数中，该函数的名称为您注释：

void copy_string(char *s, char *t)
{
    *s = *t;
    while (*t != '\0') {
        t++;
        s++;
        *s = *t;
    }
}

唯一不这样做的原因是，如果性能是一个问题，并且性能分析确实表明功能开销很大。

最清楚的是什么。通常，这是一个紧凑且易于理解的代码片段，不需要注释，就像第二个示例一样。

通常，较短的代码段更易于理解，因为读者一次也不必费神。显然，当代码过于混淆时有一个限制，我并不是说应该修剪提高清晰度的空白。

注释永远不要声明代码中显而易见的任何内容，而只是使读者两次阅读相同的内容。对我来说，第一个摘要需要澄清。开发人员为什么不使用do...while循环来删除重复的*s = *t;作业？我必须解析更多代码才能意识到它正在实现字符串副本。在这段较长的代码上，注释比在较短的代码上更有用。

关于第二个代码段的注释几乎是多余的，因为while循环实际上是惯用的，但是它确实说了代码在比代码本身更高的层次上所做的工作，这使它成为有用的注释。

问题在于没有明确的定义，short fancy code因为它很大程度上取决于程序员的水平。虽然有些人在理解while(*s++ = *t++);表达式时没有问题，但其他人会。

就我个人而言，我认为它具有while(*s++ = *t++);很好的可读性，而较长的则很难阅读。其他人可能不同意。

无论如何，这只是使用常识的问题。一定要优先考虑可读性，但是有一点会说，较长的代码变得更长时，其可读性就会降低。从我的经验来看，细节常常会降低可读性。

我必须不同意这里的大多数其他答案-我认为（至少在这种情况下）较短的代码更好。与您的主张相反，较长的代码至少对于读者而言“ 并不容易”。如果有的话，即使它使代码更难以理解和/或确保正确的操作，您似乎也想延长它的时间。

尤其是具有外循环的字符串的第一个字节的分配，从分配分开的其他字节，手段之一必须多小心阅读，以确保所有字节正确地复制。较短版本中的基本操作顺序更容易验证。唯一真正的问题是格式设置-当您有一个故意为空的循环正文时，最好将其弄清楚，例如：

while (*dest++ = *source++)
    ;

甚至：

while (*dest++ = *source++)
    ; /* no body */

有些人更喜欢使用括号：

while (*dest++ = *source++)
    {}

不管您希望使用哪种确切格式，都已经对诸如以下内容犯了足够的错误：

if (x>y);
     x = z;

...很重要的一点是要确保1）显而易见，任何流控制实际上控制着什么，以及2）显而易见，代码是在知道由其控制的情况下编写的，因此读它的人不会浪费时间去尝试弄清楚他们是否刚刚发现了错误。

Keep it simple, stupid!

确保任何其他程序员都可以理解您的代码的功能- 乍一看甚至更好（这是好名字和注释出现的地方）。

以（也许是不必要的和过早的）优化的名义花哨的纠结功夫和内联汇编都是很棒的，但是当您两个月后遇到一个bug 时，即使您甚至不理解您编写的代码。什么意思呢？您会浪费时间和精力。

在这些情况下，我经常提到Python的Zen。尤其是：

Explicit is better than implicit.
Simple is better than complex.

不要在生产软件中编写奇特的代码。我知道能够实际编写它感觉很好，而且它更短。编写奇特的代码会大大增加“ WTF /分钟”值，换句话说，会降低质量。

当然，这完全取决于环境。但总的来说，我发现这是一个很好的经验法则：

调试的难度是一开始编写代码的两倍。因此，如果您尽可能聪明地编写代码，那么根据定义，您就不够聪明，无法对其进行调试。

〜布赖恩·克尼根（Brian Kernighan）

以我的经验，就短代码而言，最大的胜利往往是使用递归而不是迭代。乍看之下，这也是最难理解的事情之一，除非您使用的语言总是递归的。对于它提供的优雅和快速的开发，我还是会喜欢它，但是我尝试确保它对将来的维护者或我自己的未来看起来是不透明的，并附有详细的评论。

我开始不再相信评论。通常，注释不会在代码更新时更新，并且注释已过时，或者表示来自客户/管理部门的不再相关的规则。

在某些情况下，注释甚至与描述的代码都不匹配，这已经到了关键的程度。

如果我有短/幻想和之间选择较长/更容易理解，然后我总是选择后者，除非有真正的好理由。

可读性和可维护性是关键，而第二个示例（即更长的示例）则更多。但是为什么要限制自己有两个选择呢？甚至更长的代码也太复杂（IMHO），以至于无法进一步注释。我将其放在具有合适的Javadoc（或任何其他名称）和合适的方法名称的方法中。