我們鼓勵在編程時應有清晰的哲學思維，而不是給予硬性規則。並不希望你們能認可所有的東西，因爲它們只是觀點，觀點會隨着時間的變化而變化。
1 、排版問題
程序是一種出版物。意味着程序員們會先閱讀（也許是幾天、幾周或幾年後的你自己閱讀），最後才輪到機器。機器的快樂就是程序能編譯，機器纔不在乎程序寫的有多麼漂亮，可是人們應該保持程序的美觀。
有時人們會過度關心：用漂亮的打印機呆板地打印出漂亮的輸出，而這些輸出只是將所有介詞用英文文本以粗體字體凸顯出來，都是些與程序無關的細節。雖然有很多人認爲程序就應該像 Algol.68 所描述的一樣（有些系統甚至要求照搬該風格編寫程序），可清晰的程序不會因爲這樣的呈現而變得更清晰，只會使糟糕的程序變得更可笑。
對於清晰的程序來說，排版規範一向都是至關重要的。當然，衆所周知最有用的是縮進，但是當墨水遮蓋了意圖時，就會控制住排版。因此即便堅持使用簡單的舊打字機輸出，也該意識到愚蠢的排版。避免過度修飾，比如保持註釋的簡潔和靈活。通過程序整齊一致地說出想表達的。接着往下看。
2 、變量命名
對於變量名稱，長度並不是名稱的價值所在，清晰的表達纔是。
不常用的全局變量可能會有一個很長的名稱，像 maxphysaddr。在循環中每一行所使用的數組索引，並不需要取一個比 i 更詳盡的名字。取 index 或者 elementnumber 會輸入更多的字母（或調用文本編輯器），並且會遮蓋住計算的細節。當變量名稱很長時，很難明白髮生了什麼。
在一定程度上，這是排版問題，看看下面
vs
現實例子中的問題會變得更糟。所以僅需把索引當成符號來對待。
指針也需要合理的符號。np 僅僅只是作爲指針 nodepointer 的助記符。如果一貫都遵從命名規範，那麼很容易就能推斷出 np 表示“節點指針”。在下一篇文章中會提到更多。
同時在編程可讀性的其它方面，一致性也是極其重要的。假使變量名爲 maxphysaddr，則不要給同級關係的變量取名 lowestaddress。
最後，我傾向於「最小長度」但「最大信息量」的命名，並讓上下文補齊其餘部分。
例如：全局變量在使用時很少有上下文幫助理解，那麼它們的命名相對而言更需要令人易懂。因此我稱 maxphyaddr 作爲一個全局變量名，對於在本地定義和使用的指針來說 np 並不一定是 NodePoint。這是品味的問題，但品味又與清晰度相關。
我避免在命名時嵌入大寫字母；它們的閱讀舒適性太彆扭了，像糟糕的排版一樣令人心煩。
3 、指針的使用
C語言不同尋常，因爲它允許指針指向任何事物。指針是鋒利的工具，像任何這樣的工具一樣，使用得當可以產生令人愉悅的生產力，但使用不當也可以造成極大的破壞。
指針在學術界的名聲不太好，因爲它太危險了，莫名其妙地就變得糟糕的不行。但我認爲它是強大的符號，它可以幫助我們清楚地自我表達。
思考：當有指針指向對象時，對於那個對象，確切地說它只是名稱，其它什麼也不是。聽起來很瑣碎，但看看下面的兩個表達式：
第一個指向一個 node（節點），第二個計算爲（可以說）同一個 node。
但第二種形式是不太容易理解的表達式。這裏解釋一下，因爲我們必須要知道 node 是什麼，i 是什麼，還要知道 i 和 node 與周圍程序之間相關的規則是什麼。孤立的表達式並不能說明 i 是 node 的有效索引，更不用提是我們想要元素的索引。
如果 i、j 和 k 都是 node 數組中的索引將很容易出差錯，而且連編譯器都不能幫助找出錯誤。當給子程序傳參數時，尤其容易出錯：指針只是一個單獨的參數；但在接收的子程序中必須認爲數組和索引是一體的。
計算爲對象表達式本身，比該對象的地址更不易察覺，而且容易出錯。正確使用指針可以簡化代碼：
vs
如果想取下一個元素的 type 可以是
或
i 前移，但其餘的表達式必須保持不變；用指針的話，只需要做一件事，就是指針前移。
把排版因素也考慮進來。對於處理連續的結構體來說，使用指針比用表達式可讀性更好：只需要較少的筆墨，而且編譯器和計算機的性能消耗也很小。與此相關的問題是，指針類型會影響指針正確使用，這也就允許在編譯階段使用一些有用的錯誤檢測，來檢查數組序列不能分開。而且如果是結構體，那麼它們的標籤字段就是其類型的提示。因此
是足以讓人明白的。如果是索引數組，數組將取一些精心挑選的名字，而且表達式也會變得更長：
此外，由於例子變得越來越大，額外的字符更加讓人惱火。
一般來說，如果發現代碼中包含許多相似並複雜的表達式，而且表達式計算爲數據結構中的元素，那麼明智地使用指針可以消除這些問題。考慮一下
看起來像利用複合表達式表示 p。有時這值得用一個臨時變量（這裏的 p）或者把運算提取成一個宏。
4 、過程名稱
過程名稱應該表明它們是做什麼的，函數名稱應該表明它們返回什麼。函數通常在像 if 這樣的表達式使用，因此可讀性要好。
是沒有太大幫助的，因爲不能推斷出 checksize 錯誤時返回 true，還是非錯誤時返回。
相反使這點能清晰表達，並且在常規使用中將來也不大可能出錯。
5、 註釋
這一個微妙的問題，需要自己體會和判斷。由於一些原因，我傾向於寧可清除註釋。第一，假如代碼清晰，並且使用了規範的類型名稱和變量名稱，應該從代碼本身就可以理解。第二，編譯器不能檢查註釋，因此不能保證準確，特別是代碼修改過以後。誤導性的註釋會非常令人困惑。第三，排版問題：註釋會使代碼變得雜亂。
但有時我會寫註釋，像下文一樣僅僅只是把它們用於介紹。例如：解釋全局變量的使用和類型（我總是在龐大的程序中寫註釋）；作爲一個不尋常或者關鍵過程的介紹；或標記出大規模計算的一節。
有一個糟糕註釋風格的例子：
還有更糟糕的做法：
先不要嘲笑，等到在現實中看到再去吧。
或許除了諸如重要數據結構的聲明（對數據的註釋通常比對算法的更有幫助），這樣至關重要部分之外，需要避免對註釋的“可愛”排版和大段的註釋；基本上最好就不要寫註釋。如果代碼需要靠註釋來說明，那最好的方法是重寫代碼，以便能更容易地理解。這就把我們帶到了複雜度。
6 、複雜度
許多程序過於複雜，比需要有效解決的問題更加複雜。這是爲什麼呢？大部分是由於設計不好，但我會跳過這個問題，因爲這個問題太大了。然而程序往往在微觀層面就很複雜，有關這些可以在這裏解決。
● 規則 1：不要斷定程序會在什麼地方耗費運行時間。瓶頸總是出現在令人意想不到的地方，直到證實瓶頸在哪，不要試圖再次猜測並加快運行速度。
● 規則 2：估量（measure） 在沒有對代碼做出估量之前不要優化速度，除非發現最耗時的那部分代碼，要不也不要去做。
● 規則 3：當 n 很小時（通常也很小），花哨的算法運行很慢。花哨算法有很大的常數級別複雜度。在你確定 n 總是很大之前， 不要使用花哨算法。（即使假如 n 變大，也優先使用規則 2）.例如，對於常見問題，二叉樹總比伸展樹高效。
● 規則 4：花哨的算法比簡單的算法更容易有 bug，而且實現起來也更困難 儘量使用簡單的算法與簡單的數據結構。
以下幾乎是所有實際程序中用到的數據結構：
● 數組
● 鏈表
● 哈希表
● 二叉樹
當然也必須要有把這些數據結構靈活結合的準備，比如用哈希表實現的符號表，其中哈希表是由字符型數組組成的鏈表。
● 規則 5：以數據爲核心 如果選擇了適當的數據結構並把一切都組織得很有條理性，算法總是不言而喻的。編程的核心是數據結構，而不是算法。（參考 Brooks p. 102）
● 規則 6：就是沒有規則 6。
7 、數據編程
不像許多 if 語句，算法或算法的細節通常以緊湊、高效和明確的數據進行編碼。眼前的工作可以編碼，歸根到底是由於其複雜性都是由不相干的細節組合而成。
分析表是典型例子，它通過一種解析固定、簡單代碼段的形式，對編程語言的語法進行編碼。有限狀態機特別適合這種處理形式，但是幾乎任何涉及到對構建數據驅動算法有益的程序，都是將某些抽象數據類型的輸入“解析”成序列，序列會由一些獨立“動作”構成。
也許這種設計最有趣的地方是表結構有時可以由另一個程序生成（經典案例是解析生成器）。
有個更接地氣的例子，假如操作系統是由一組表驅動，這組表包含連接 I/O 請求到相應設備驅動的操作，那麼可以通過程序“配置“系統，該程序可以讀取到某些特殊設備與可疑機器連接的描述，並打印相應的表。
數據驅動程序在初學者中不常見的原因之一是由於 Pascal 的專制。Pascal 像它的創始人一樣，堅信代碼要和數據分開。因而（至少在原始形式上）無法創建初始化的數據。
與圖靈和馮諾依曼的理論背道而馳，這些理論可都是定義存儲計算機的基本原理。代碼和數據是一樣的，或至少可以算是。還能怎樣解釋編譯器的工作原理呢？（函數式語言對 I/O 也有類似的問題）
8、 函數指針
Pascal 專制的另一個結果是初學者不使用函數指針。（在 Pascal 中沒有把函數作爲變量） 用函數指針來處理編碼複雜度會有一些令人感興趣的地方。
指針指向的程序有一定的複雜度。這些程序必須遵守一些標準協議，像要求一組都是相同調用的程序就是其中之一。除此之外，所要實現的只是完成業務，複雜度是分散的。
有個協議的主張是既然所有使用的功能相似，那麼它們的行爲也必須相似。這對簡單的文檔、測試、程序擴展和甚至使程序通過網絡分佈都有幫助——遠程過程調用可以通過該協議進行編碼。
我認爲面向對象編程的核心是清晰使用函數指針。規定好要對數據執行的一系列操作，以及對這些操作響應的整套數據類型。
將程序合攏到一起最簡單的方法是爲每種類型使用一組函數指針。簡而言之，就是定義類和方法。當然，面嚮對象語言提供了更多更漂亮的語法、派生類型等等，但在概念上幾乎沒有提出額外的東西。
數據驅動程序與函數指針的結合，變成了一種表現令人驚訝的工作方法。根據我的經驗，這種方法經常會產生驚喜的結果。即使沒有面嚮對象語言，無需額外的工作也可以獲得 90％ 的好處，並且能更好地管理結果。
我無法再推薦出更高標準的實現方式。我所有的程序都是由這種方式組織管理，而且經過多次開發後都相安無事——遠遠優於缺少約束的方法。也許正如所說：從長遠來看，約束會帶來豐厚的回報。
9 、包含文件
簡單規則：包含（include）文件時應該永遠不要嵌套包含。如果聲明(在註釋或隱式聲明裏)需要的文件沒有優先包含進來，那麼使用者（程序員）要決定包含哪些文件，但要以簡單的方式處理，並採用避免多重包含的結構。
多重包含是系統編程的禍根。將文件包含五次或更多次來編譯一個單獨的 C 源文件的事情屢見不鮮。Unix 系統中 /usr/include/sys 就用了這麼可怕的方式。
說到 #ifdef，有一個小插曲，雖然它能防止讀取兩次文件，但實際上經常用錯。#ifdef 是定義在文件本身中，而不是文件包含它。結果是常常導致讓成千上萬不必要的代碼通過詞彙分析器，這是(優秀編譯器中)耗費最大的階段。
只需遵從以上簡單規則，就能讓你的代碼變得優雅而美觀，至少也是賞心悅目，從技術變成藝術~~
最後養成一個良好的編程習慣
（1）在比較複雜的代碼後面要有註釋。如果光溜溜一堆代碼，別人就不可能看懂你的代碼，而且也不利於查找錯誤。除非你一直編東西給自己看。能在代碼裏說明白的就一定要在代碼裏體現。比如變量名、函數名，在命名的時候儘量說明是幹什麼用的。
（2）注意語句的嵌套不要太長，把主函數儘量寫簡短。經常看到別人的代碼是主函數只有幾行，幾個函數調用，而定義全在主函數外部。這樣一是減少了主函數內部的嵌套，二是比較精簡，容易讀懂。
（3）注意語句的選擇。並不是分支語句就用if循環就用while、for。在適當的情況下switch和dowhile語句也是要用的。在某些時候，switch語句比if語句更加精練明瞭，而dowhile比while少一個循環。
對於熱愛編程的人來說，有一羣一起學習一起解答的小夥伴很重要！
小編有一個免費的C/C++編程學習交流俱樂部，【點擊進入】！
還有編程學習文件（源碼，零基礎教程，項目實戰教學視頻），歡迎初學者和正在進階中的小夥伴們！