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中你也可以在每個作用域的開頭聲明變量（在循環示例中），這既實用又簡潔。