C 語言代碼評審實戰：七大常見問題與改進指南

前言：為什麼代碼評審不可或缺？

在實際軟體開發專案中，代碼評審是保障代碼品質的關鍵環節。它不僅能及早發現程式邏輯錯誤、潛在 Bug，還能統一團隊編碼風格、促進知識傳遞，最終提升整體開發效能。評審流程通常包括：會前準備、會中朗讀代碼與討論記錄、會後追蹤整改。

實戰總結：C 語言代碼評審中高頻的 7 大問題

近期參與多次 C 語言代碼評審，發現以下問題普遍存在，特整理供開發人員參考。

1. 缺乏必要的註釋說明

許多開發者視註釋為可有可無，實則不然。缺乏註釋的代碼在演進數個版本後，連原作者都難以回憶初衷。良好的註釋是合格程式設計師的基本素養，請在關鍵邏輯、複雜演算法、介面定義處務必添加清晰說明。

2. 關鍵分支缺少日誌，導致問題排查困難

在 return 前或 else 分支未輸出日誌，會使執行路徑難以追蹤。例如連續多個 if (var > 0) return; 時，若無日誌無法得知是哪個條件觸發返回。

改進示例：

if (var1 > 0) { LOG("var1 異常"); return; }
if (var2 > 0) { LOG("var2 異常"); return; }
if (var3 > 0) { LOG("var3 異常"); return; }

同理，else 分支返回前也應加日誌，確保可追溯性。

3. 魔術數字滿天飛，可讀性極差

直接使用 100、200 等字面常數，讓人無法理解其業務含義。應使用宏或 enum 賦予語義：

#define SIZE_SMALL  100
#define SIZE_MEDIUM 200
#define SIZE_LARGE  300

if (var == SIZE_SMALL)  { ... }
else if (var == SIZE_MEDIUM) { ... }

4. 字串操作未檢查長度，隱患緩衝區溢位

使用 strcpy、memcpy 時未驗證目標緩衝區大小，極易導致記憶體越界崩潰。務必改用 strncpy 並預先計算長度：

char src[100] = {0};
char dest[80] = {0};
size_t len = strlen(src);
if (len >= sizeof(dest)) len = sizeof(dest) - 1;
strncpy(dest, src, len);

5. if-else 判斷條件混用多個變數，邏輯混亂

同層 if-else if 鏈中混用 var1、var2、var3 作為判斷條件，極易誤讀且難以維護。應拆分為巢狀結構，確保同層條件變數一致：

if (var1 == SMALL) { ... }
else if (var1 == MEDIUM) { ... }
else {
    if (var2 == BIG) { ... }
    else { ... }
}

6. 變數定義排版混亂，影響閱讀體驗

不同類型變數雜糅宣告，導致代碼雜亂無章。建議：同類型歸組、縮進對齊、空行分隔。

int i = 0;
int j = 0;
int max = 0;

char str1[50] = {0};
char str2[500] = {0};
char str3[1000] = {0};

char *pStr = NULL;
TestStruct_T tTestStruct = {0};

7. 函數參數合法性未校驗，特別是指標

直接使用傳入指標而不判空，是崩潰高發區。進入函數第一時間驗證輸入參數：

void TestFun(char *pMsg) {
    if (pMsg == NULL) {
        printf("TestFun: pMsg is NULL!\n");
        return;
    }
    // 後續邏輯...
}

總結與心法

代碼評審不僅是找 Bug，更是自我思維的校準。評審時應秉持實事求是態度：不因顧及情面而隱瞞問題，不因代碼缺陷而人身攻擊。團隊共同目標只有一個——把產品做好。