C語言程式設計原理

喜歡維護性。不需要聰明時不要聰明。相反，尋求滿足要求的最簡單和最易理解的解決方案。大多數問題，包括效能，相對可維護性是次要的。你應該對你的程式碼有一個效能估算尺寸，在這個尺寸你儘可以大膽放心為可維護下考慮設計。

更重要的是，讓新手能夠理解你的程式碼，不要使用一些有趣的方式來解決問題，這樣會妨礙他們理解。理想情況下，新手將會理解你的程式碼並從中學到東西。寫程式碼時，想象一下，維護程式碼的人好像應該就是去年的你。

避免魔法。不要使用宏。不要使用typedef隱藏指標或避免寫“struct”。避免編寫複雜的抽象。保持您的構建系統簡單和透明。不要使用愚蠢的hacky crap，不能因為它是解決這個問題的一個很酷的方法。即使沒有上下文，你的程式碼的基本行為應該是明顯的。

C的最大優點之一是其透明性和簡單性。這個優點應該被積極擁抱，而不是顛覆。

識別和避免危險模式。不要使用固定大小的緩衝區 - 這總是要計算需要多少空間並分配它。需要將不安全的使用者輸入轉換為乾淨的C結構。如果以後必須向使用者提供此資料，請將其儲存在C結構中，直到最後一個可能的時刻。學習和使用需額外敏感關心的函式像strcat。

寫C有時像玩槍。槍是很重要的工具，但如果出了事故可能非常糟糕。你必須小心的對待槍支：你不要指向任何你喜歡的東西，你需要有良好紀律去使用它，你對待它就像它總是載入子彈一樣。就像槍是用在能將物體擊穿成洞一樣，C在寫核心時是有用的。

需要關心組織程式碼。不要將程式碼放在一個header中。不要使用 inline關鍵字。分離關注到單獨的檔案中。使用靜態函式來組織你的邏輯。使用一種編碼風格，給予一切足夠的空間，這樣眼睛才容易看得過來。當目的是不言而喻的時，使用單字母變數名；不是時，使用描述性的名字。

我喜歡將我的程式碼組織成實現一些組函式的目錄，並給每個函式自己的檔案。這個檔案通常包含許多靜態函式，但它們都用於組織這個檔案負責實現的行為。寫一個header能讓其他人訪問這個模組。並使用Linux核心的編碼風格。

僅使用標準功能。不要假定平臺是Linux。不要假定編譯器是gcc。不要假定libc是glibc。不要假設架構是x86。不要假設coreutils是GNU。不要定義_GNU_SOURCE。

如果必須使用特定平臺的功能，請為其描述介面，然後單獨編寫特定平臺的支援程式碼。在任何情況下都不應該使用gcc擴充套件或glibc擴充套件。GNU已經枯萎，不要讓它侵染你的程式碼。

使用規範的工作流程。有一個嚴格的版本控制方法。編寫周到的提交訊息 - 簡要解釋第一行中的更改，並在擴充套件提交訊息中為其新增正當理由。在功能分支中使用明確定義的目標，並且不要包括不服務該目標的任何更改。不要害怕改變和編輯您的分支的歷史，以便更清楚地顯示您的修改。

當你以後返回到你的程式碼時，你會感謝你自己寫的詳細的提交訊息。其他與您的程式碼互動的人也將感謝這一點。當你看到一些愚蠢的程式碼，很高興地能夠知道這個混蛋在當時的想法，特別是當這個有問題的混蛋正好是你。

做嚴格的測試和審查。確定您的更改可能採用不同的可能程式碼路徑。測試他們的正確行為。給它不正確的輸入。給它可能“永不發生”的輸入。特別注意容易出錯的模式。尋找地方來簡化程式碼，使過程更清晰。

接下來，將您的更改提交給其他人稽核。這個人應該應用相同的過程，並簽署您的更改。還要遵守紀律，採取所有相同的步驟。

從錯誤中學習。首先，修復bug。然後，修復真正的bug：因為你的程式竟然允許這個bug發生。讓你的程式碼審查者參與討論 - 這也有他們的錯。嚴格檢查編寫，審查和部署此程式碼的過程，並找出根本原因。

重要的是要記住規則是用來被打破。

Principles for C programming - Drew DeVault’s Blog