条件中的条件条件分配是一种不良习惯吗？

假设我想编写一个在C中连接两个字符串的函数。我的编写方式是：

void concat(char s[], char t[]){
    int i = 0;
    int j = 0;

    while (s[i] != '\0'){
        i++;
    }

    while (t[j] != '\0'){
        s[i] = t[j];
        i++;
        j++;
    }

    s[i] = '\0';

}

但是，K＆R在他们的书中以不同的方式实现了它，尤其是在while循环的条件部分中尽可能多地包括：

void concat(char s[], char t[]){
    int i, j;
    i = j = 0;
    while (s[i] != '\0') i++;

    while ((s[i++]=t[j++]) != '\0');

}

首选哪种方式？是鼓励还是不鼓励以K＆R的方式编写代码？我相信我的版本会更容易被其他人阅读。

总是要比清晰更聪明。在过去的几年中，最好的程序员是没人能理解的代码。他们说：“我无法理解他的密码，他一定是个天才。” 如今，最好的程序员是任何人都可以理解的代码。现在，计算机时间比程序员的时间便宜。

任何傻瓜都可以编写计算机可以理解的代码。好的程序员编写人类可以理解的代码。（福勒先生）

因此，毫无疑问，我会选择选项A。这是我的明确答案。

与图兰斯·科尔多瓦（TulainsCórdova）的答案相同，黄金法则是确保编写可理解的代码。但是我不同意这个结论。黄金法则意味着编写代码，最终将维护您的代码的典型程序员可以理解。而且，你是谁在典型的程序员谁最终会维护你的代码是最好的裁判。

对于不是以C开头的程序员，由于您已经知道的原因，第一个版本可能更容易理解。

对于那些使用C风格长大的人来说，第二个版本可能更容易理解：对他们来说，代码的作用是同等理解的，对他们来说，它为什么会按原样编写以及对他们来说却留下了更少的问题。 ，较少的垂直空间意味着可以在屏幕上显示更多上下文。

您将不得不依靠自己的良好意识。您想让哪些读者最容易理解您的代码？此代码是为公司编写的吗？那么目标受众可能是该公司中的其他程序员。这是一个个人爱好项目，只有您自己可以从事吗？那么您就是您自己的目标受众。您要与他人共享此代码吗？那么其他人就是您的目标受众。选择与该受众群体匹配的版本。不幸的是，没有单一的鼓励方式。

编辑：该行s[i] = '\0';已添加到第一个版本，从而按照下面的变体1中的描述进行了修复，因此这不再适用于问题代码的当前版本。

第二个版本的独特优势是correct，而第一个版本则不是-不会正确终止目标字符串的空值。

“状态分配”允许非常简洁地表达“ 在检查空字符之前复制每个字符”的概念，并以某种方式使编译器的优化更加容易，尽管如今许多软件工程师发现这种代码的可读性较差。如果您坚持使用第一个版本，则必须

1. 在第二个循环结束后添加空终止（添加更多代码，但是您可以说可读性值得）或
2. 将循环体更改为“首先分配，然后检查或保存分配的字符，然后递增索引”。在循环的中间检查条件意味着打破循环（降低清晰度，大多数纯粹主义者不赞成这样做）。保存分配的字符将意味着引入一个临时变量（降低清晰度和效率）。在我看来，这两者都会消灭优势。

TulainsCórdova和hvd的答案很好地涵盖了清晰度/可读性方面。让我将范围界定作为支持条件分配的另一个原因。条件中声明的变量仅在该语句的范围内可用。您以后不能偶然使用该变量。该用于循环已经做了好久了。同样重要的是，即将发布的C ++ 17 为if和switch引入了类似的语法：

if (int foo = bar(); foo > 42) {
    do_stuff();
}

foo = 23;   // compiler error: foo is not in scope

否。这是非常标准的标准C风格。您的示例是一个糟糕的示例，因为它应该只是一个for循环，但总的来说没有错

if ((a = f()) != NULL)
    ...

例如（或同时使用）。

在K＆R时代

• “ C”是便携式汇编代码
• 被汇编语言思想的程序员所使用
• 编译器没有做太多优化
• 大多数计算机具有“复杂指令集”， 例如，while ((s[i++]=t[j++]) != '\0')将映射到大多数CPU上的一条指令（我希望使用Dec VAC）

有几天

• 大多数阅读C代码的人都不是汇编代码程序员
• C编译器进行了大量优化，因此，更易于阅读的代码可能会转换为同一机器代码。

（有关始终使用花括号的说明-第一组代码由于具有一些“不需要的”而占用更多空间{}，以我的经验，这些通常可以防止编译器严重合并的代码并允许使用错误的“;”位置进行错误处理。被工具检测到。）

但是，在过去，该代码的第二版会被阅读。（如果我做对了！）

concat(char* s, char *t){      
    while (*s++);
    --s;
    while (*s++=*t++);
}

即使完全能够做到这一点，也是一个非常糟糕的主意。俗称“世界上的最后一个错误”，如下所示：

if (alert = CODE_RED)
{
   launch_nukes();
}

虽然你可能不会犯了一个错误这是非常，严重的，它很容易不小心搞砸了，并在你的代码库导致难以发现错误。大多数现代编译器都会在条件内为分配插入警告。它们在那里是有原因的，您最好注意它们，并避免这种构造。

两种样式都格式正确，正确且适当。哪一种更合适，很大程度上取决于您公司的风格准则。现代IDE将通过使用实时语法表皮来方便地使用这两种样式，这些语法显式地突出显示了可能会引起混乱的区域。

例如，以下表达式由Netbeans突出显示：

if($a = someFunction())

以“偶然指派”为理由。

为了明确地告诉Netbeans：“是的，我真的想这样做...”，可以将表达式包装在一组括号中。

if(($a = someFunction()))

归根结底，这一切都归结为公司风格准则以及可用于促进开发过程的现代工具的可用性。