本文只是本人的閱讀筆記，作筆記時有改動。詳細指南請參見鏈接：原指南
0 前言
編輯高手：能長期穩定地編寫出高難度、高質量程序的程序員。
編程老手：能長期穩定地編寫出高質量程序的程序員。
根據上述定義，馬上得到第一推論：我既不是高手也算不上是老手。
1.1 版本和版本的聲明
（1）版權信息。
（2）文件名稱，標識符，摘要。
（3）當前版本號，作者/修改者，完成日期。
（4）版本歷史信息。
例子見原文示例1-1。
1.2 頭文件的結構
（1）頭文件開頭處的版權和版本聲明（參見原文示例1-1）。
（2）預處理塊。
（3）函數和類結構聲明等。
【預處理塊中的“ifndef/define/endif結構”是本人忽視的，只有在寫大作業時才注意。】
#ifndef FILE_H
#define FILE_H
//內容
#endif【不提倡使用全局變量，儘量不要在頭文件中出現象extern int value 這類聲明】
1.3 定義文件的結構
（1） 定義文件開頭處的版權和版本聲明（參見示例1-1）。
（2） 對一些頭文件的引用。
（3） 程序的實現體（包括數據和代碼）。
1.4 頭文件的作用
【略】
1.5 目錄結構
【略，不清楚】
2.1 空行
空行不會浪費內存，雖然打印含有空行的程序是會多消耗一些紙張，但是值得。
（1）在每個類聲明之後、每個函數定義結束之後都要加空行。
（2）在一個函數體內，邏揖上密切相關的語句之間不加空行，其它地方應加空行分隔。
2.2 代碼行
（1）一行代碼只做一件事情，如只定義一個變量，或只寫一條語句。這樣的代碼容易閱讀，並且方便於寫註釋。
【本人有時會在一行連續定義相同類型的變量，這樣不好！】
（2）if、for、while、do等語句自佔一行，執行語句不得緊跟其後。不論執行語句有多少都要加{}。
【本人不注意，喜歡寫緊湊點，不知道是哪裏看的，{要跟在後面，現在還是採用本文的建議把，讓{也佔一行，一個語句也加{}】
（3）儘可能在定義變量的同時初始化該變量（就近原則），減少隱患。
2.3 代碼行內的空格
【代碼行內的空格都是本人不注意的！】
（1）關鍵字之後要留空格。象const、virtual、inline、case 等關鍵字之後至少要留一個空格，否則無法辨析關鍵字。象if、for、while等關鍵字之後應留一個空格再跟左括號‘（’，以突出關鍵字。
（2）函數名之後不要留空格，緊跟左括號‘（’，以與關鍵字區別。
（3）向後跟隨： （
（4）向前緊隨： ） ， ;
（5），之後要留空格，如Function(x, y, z)。
;類似如for (initialization; condition; update)。
（6）賦值操作符、比較操作符、算術操作符、邏輯操作符、位域操作符，如“=”、“+=”、“>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“<<”,“^”等二元操作符的前後應當加空格。
（7）一元操作符的前後如“!”、“~”、“++”、“–”、“&”（地址運算符）等不加空格。
（8）“［］”、“.”、“->”這類操作符前後不加空格。
（9）對於表達式比較長的for語句和if語句，爲了緊湊起見可以適當地去掉一些空格，如for (i=0; i<10; i++)和if ((a<=b) && (c<=d))。
2.4 對齊
【這主要關於 { 與 } 的，但我之前都沒有注意】
（1）{與}獨佔一行，位於同列，注意縮進。
（2）{ }內的代碼塊在{ 的右邊數格對齊。
2.5 長行拆分
長表達式要在低優先級操作符處拆分成新行，操作符放在新行之首（以便突出操作符）。拆分出的新行要進行適當的縮進，使排版整齊，語句可讀。
2.6 修飾符的位置
修飾符 * 和 ＆ 應該靠近數據類型還是該靠近變量名，是個有爭議的活題。
若將修飾符 * 靠近數據類型，例如：int* x; 從語義上比較直觀，即x是int 類型的指針。
弊端是易誤解，例如：int* x, y; 此處y容易被誤解爲指針變量。雖然將x和y分行定義可以避免誤解，但並不是人人都願意這樣做。
2.7 註釋
（1）註釋是對代碼的“提示”，而不是文檔。程序中的註釋不可喧賓奪主，註釋太多了會讓人眼花繚亂。註釋的花樣要少。
（2）邊寫代碼邊註釋，修改代碼同時修改相應的註釋。
（3）【儘量避免在註釋中使用縮寫，特別是不常用縮寫？】
（4）註釋位置不可放在下方。
（5）【代碼比較長，特別是有多重嵌套時，應當在一些段落的結束處加註釋，便於閱讀。這個從來沒注意哈】
2.7 類的版式
建議讀者“以行爲爲中心”的書寫方式，首先考慮類的函數。這是很多人的經驗——“這樣做不僅讓自己在設計類時思路清晰，而且方便別人閱讀。因爲用戶最關心的是接口，誰願意先看到一堆私有數據成員！”