C99在开源项目中混合了声明和代码？

Question

为什么C99混合声明和代码没有在Linux内核或GNOME等开源C项目中使用 ？

我非常喜欢混合声明和代码，因为它使代码更具可读性，并且通过将变量的范围限制在最窄的范围内来防止难以看到错误。 这是Google for C ++推荐的。

例如，Linux至少需要 GCC 3.2，而GCC 3.1 支持 C99混合声明和代码

Answer 1

你不需要混合声明和代码来限制范围。 你可以做：

{
  int c;
  c = 1;
  {
    int d = c + 1;
  }
}

在C89。 至于为什么这些项目没有使用混合声明（假设这是真的），它很可能是“如果没有破坏就不修复它”的情况。

Answer 2

这是一个老问题，但我将建议惯性是大多数这些项目仍然使用ANSI C声明规则的原因。

然而，还有许多其他可能性，从有效到荒谬：

• 可移植性。 许多开源项目都假设迂腐ANSI C是编写软件最便携的方式。

• 年龄。 其中许多项目早于C99规范，作者可能更喜欢一致的编码风格。

• 无知。 程序员提交早期C99并且不知道混合声明和代码的好处。 （替代解释：开发人员充分意识到潜在的权衡，并决定混合声明和声明是不值得的。我非常不同意，但很少有两个程序员会就任何事情达成一致。）

• FUD。 程序员将混合声明和代码视为“C ++主义”并因此而不喜欢它。

Answer 3

没有理由重写Linux内核来进行不会提高性能的外观修改。

如果代码库正在运行，那么为什么要出于美观的原因进行更改呢？

Answer 4

我不记得在内核代码的样式指南中对此有任何阻止。 但是，它确实说功能应该尽可能小，只做一件事。 这可以解释为什么声明和代码的混合很少见。

在一个小函数中，在范围的开始处声明变量就像一种Introit ，告诉你一些关于即将发生的事情。 在这种情况下，变量声明的移动是如此有限，以至于它可能没有任何效果，或者可以通过将巴克推入人群来隐藏有关功能的一些信息，可以这么说。 有一个原因是在他进入房间之前宣布国王的到来。

OTOH，一个必须混合变量和代码才能读取的函数可能太大了。 这是一个标志（以及过于嵌套的块，内联注释和其他东西），函数的某些部分需要被抽象为单独的函数（并声明为static ，因此优化器可以内联它们）。

在函数开头保留声明的另一个原因是：如果需要重新排序代码中语句的执行，可以将变量移出其作用域而不会意识到，因为在代码中间声明了变量的作用域在缩进中不明显（除非您使用块来显示范围）。 这很容易修复，所以这只是一个烦恼，但新代码经常会经历这种转变，烦恼可能是累积的。

另一个原因是：您可能想要声明一个变量来从函数中获取错误返回代码，如下所示：

void_func();
int ret = func_may_fail();
if (ret) { handle_fail(ret) }

完全合理的事情。 但：

void_func();
int ret = func_may_fail();
if (ret) { handle_fail(ret) }
....
int ret = another_func_may_fail();
if (ret) { handle_other_fail(ret); }

哎呀！ ret定义了两次。 “那么？删除第二个声明。” 你说。 但这会使代码不对称，最终会产生更多的重构限制。

当然，我自己混合声明和代码; 没有理由对它采取教条（否则你的业力可能会超过你的教条:-)。 但你应该知道伴随的问题是什么。

Answer 5

也许它不需要，也许分离是好的？ 我是用C ++做的，它也有这个功能。

Answer 6

没有理由像这样改变代码，C99仍然没有得到编译器的广泛支持。 它主要是关于可移植性。

Answer 7

没有任何好处。 声明函数开头的所有变量（像pascal一样）要清楚得多，在C89中你也可以在每个作用域的开头声明变量（在循环示例中），这既实用又简洁。