作為全球最龐大的開源項目之一，Linux內核的代碼量早已突破千萬行。要讓來自世界各地的開發者高效協作，一套統一、嚴謹的編碼風格必不可少——這不僅是“代碼顏值”的要求，更是可讀性、可維護性的核心保障。

今天，我們就基于Linux內核官方文檔(https://www.kernel.org/doc/html/latest/process/coding-style.html)，提煉一份「內核級」編碼指南，無論你是剛接觸內核開發的新手，還是想規范代碼風格的老兵，都能從中找到實用參考。

一、基礎格式：縮進與換行，細節定成敗

內核編碼風格對“基礎格式”的要求近乎“嚴苛”，核心原則是**“視覺清晰，無歧義”**。

1.縮進：8個字符的Tab，不是空格！

?必須用Tab鍵縮進，且每個Tab對應8個字符（拒絕2/4字符縮進，文檔戲稱“把π定義為3一樣離譜”）。

?理由：深層嵌套時更容易區分代碼塊，同時警告你“嵌套過深”（超過3層就該重構了）。

?例外：僅在注釋、文檔和Kconfig中可使用空格，其他場景絕對禁止用空格縮進。

2. switch-case對齊：別搞“雙重縮進”

switch語句的case標簽需與switch對齊，而非縮進一層，避免代碼過度右移：

// 正確示例switch(suffix) {case'G':case'g': // case與switch同列    mem <<=?30; // 邏輯代碼縮進8字符   break;case'M':case'm':    mem <<=?20;   break;default:   break;}

3.行寬：80列是“軟上限”

?單行長建議不超過80列，超長時需拆分（如函數參數、長表達式），拆分后子句需“右移且短于父句”。

?例外：用戶可見字符串（如printk消息）不能拆分——否則會破壞grep搜索功能。

二、大括號與空格：內核風格的“標志性符號”

大括號（{}）和空格的位置，是內核代碼“辨識度”的關鍵，嚴格遵循K&R風格（Kernighan & Ritchie，C語言之父）。

1.大括號位置：函數單獨成行，其他“尾隨行末”

?非函數塊（if/switch/for/while）：左大括號在語句末尾，右大括號單獨成行：

if(count >0) { //左括號在末尾    do_something();}else{     //else與右括號同列    do_nothing();}

?函數定義：左大括號必須在新行開頭，與函數名對齊：

// 正確示例intcount_active_users(void){ // 左括號單獨成行   intcount =0;   // 業務邏輯   returncount;}

2.空格使用：“關鍵字要空格，函數/運算符看場景”

?關鍵字后加空格：if/switch/case/for/while后必須加空格（如if (x)，而非if(x)）。

?函數/運算符不加空格：

?sizeof/typeof/alignof后不加空格（如sizeof(struct file)，而非sizeof (struct file)）；

?指針*貼近變量名（如char *buf，而非char* buf）；

?二元運算符（=/+/-/等）前后加空格，一元運算符（&/*/~等）后不加（如*ptr，而非* ptr）。

?禁止尾隨空格：行尾不能留空格（Git會警告，編輯器可配置自動刪除）。

三、命名規范：見名知意，拒絕“花里胡哨”

內核命名的核心是**“簡潔+區分作用域”**，杜絕冗余和歧義。

1.全局變量/函數：長且descriptive

?全局符號（跨文件訪問）必須“見名知意”，禁止縮寫（如count_active_users()而非cntusr()）。

?示例：struct user *active_user_list（全局變量，明確表示“活躍用戶列表”）。

2.局部變量：短且簡潔

?局部變量（函數內使用）用短名即可，如循環計數器用i，臨時變量用tmp，無需“過度描述”（如loop_counter反而冗余）。

3.禁用“匈牙利命名”

不要在變量名中加類型前綴（如iCount、pBuf）——編譯器會檢查類型，人類加前綴只會增加冗余，還可能因類型修改導致命名失效。

4.術語替代：拒絕“master/slave”等爭議詞

?替代方案：master→primary/main，slave→secondary/replica；blacklist→denylist，whitelist→allowlist。

四、函數設計：短、精、單職責，拒絕“大而全”

內核函數的設計哲學是**“做一件事，且做好”**，具體要求如下：

1.長度與復雜度：控制在“2屏內”

?函數長度建議不超過2個屏幕（約40-50行），復雜邏輯必須拆分成helper函數（用static inline優化性能）。

?局部變量不超過5-10個：人類大腦難以同時處理超過7個變量，過多則需拆分函數。

2.函數原型：參數必須帶名

函數聲明時，參數需寫清名稱（而非僅寫類型），方便讀者理解用途：

// 正確：帶參數名voidprocess_user(structuser *u,intaction);// 錯誤：僅寫類型voidprocess_user(structuser *,int);

3.統一退出：用goto做“清理操作”

當函數有多個退出點（如分配內存后需釋放），推薦用goto統一清理，避免重復代碼：

intinit_buffer(void){   char*buf = kmalloc(SIZE, GFP_KERNEL);   if(!buf)       return-ENOMEM; // 直接退出（無清理）   if(init_data(buf) !=0) {       gotoout_free_buf; // 跳轉到清理邏輯    }   // 正常邏輯   return0;out_free_buf: // 清理標簽：命名需明確（如“釋放buf”）    kfree(buf);   return-EIO;}

注意：goto標簽需語義化（如out_free_buf），拒絕err1/err2這類無意義名稱。

五、注釋：說“做什么”，而非“怎么做”

內核注釋的核心是**“輔助理解，不冗余”**，拒絕“解釋爛代碼”。

1.注釋原則：“What> How”

?不要解釋代碼邏輯（如“i自增1”），而要說明“為什么這么做”或“做什么”（如“統計活躍用戶數，排除僵尸進程”）。

?函數注釋：放在函數前，說明功能、參數含義、返回值（推薦用內核doc格式，見Documentation/doc-guide/）。

2.多行注釋格式：左對齊星號

多行注釋需用“/* ... */”，且每行開頭加*，保持左對齊：

/** 統計系統中活躍的用戶數量* 排除條件：1. 僵尸進程對應的用戶；2. 離線超過24小時的用戶* 返回值：活躍用戶數（>=0）*/intcount_active_users(void){   // ...}

3.數據注釋：每行一個變量，加說明

聲明變量時，每行只定義一個，并用注釋說明用途：

// 正確：每行一個，帶注釋intuser_count;  // 總用戶數char*user_name; // 當前用戶名// 錯誤：多變量一行，無注釋intuser_count, *user_name;

六、實用避坑指南：這些“禁忌”別踩

1. typedef：非必要不使用

僅在以下場景可用typedef，其他情況禁止（如struct不要typedef）：

?完全opaque類型（如pte_t，只能通過接口訪問，不暴露內部結構）；

?明確的整數類型（如u8/u16/u32，避免int/long混淆）；

?稀疏檢查（sparse工具用于類型校驗）。

2.內存分配：安全優先，避免錯誤

?用sizeof(*p)而非硬寫類型：分配結構體指針時，用kmalloc(sizeof(*p), ...)，避免類型修改導致的錯誤：

// 正確：無需關心p的類型structuser *p = kmalloc(sizeof(*p), GFP_KERNEL);// 錯誤：類型修改后需同步修改這里structuser *p = kmalloc(sizeof(structuser), GFP_KERNEL);

?數組分配用kmalloc_array/kcalloc：自動檢查n * sizeof(...)溢出，返回NULL避免越界。

3.禁用BUG ()，用WARN ()替代

?不要用BUG()/BUG_ON()（會直接崩潰內核），優先用WARN_ON_ONCE()（打印警告但不崩潰，且只打印一次）。

?僅在“嚴重內存損壞，無法繼續運行”時用BUG()，且需附帶充分理由。

七、工具推薦：自動對齊，告別手動調整

內核開發有成熟工具鏈，幫你自動符合風格：

1.indent命令：內核推薦indent -kr -i8（K&R風格，8字符縮進），或直接用內核腳本scripts/Lindent。

2.clang-format：支持自動格式化代碼，還能排序#include、對齊宏定義，配置見Documentation/dev-tools/clang-format.rst。

3.編輯器配置：

?Emacs：將文檔中的.emacs配置代碼加入，自動適配內核風格；

?Vim：添加set sw=8 ts=8 expandtab!（Tab=8字符，不自動轉空格）。

總結：風格的本質是“協作”

Linux內核編碼風格看似“教條”，實則是千萬開發者協作的“共同語言”——它不追求“個性化”，而是通過統一規則降低溝通成本，讓代碼“讀起來像一個人寫的”。

最后記住：風格不是“束縛”，而是“助力”。初期可能需要刻意適應，但一旦形成習慣，你的代碼會更易維護、更易被內核社區接納。

如果在實踐中遇到風格相關的坑，歡迎在評論區分享～