關於代碼註釋
註釋的種類可以分成五類：
代碼的重複
重複的註釋，用不同的詞重申了代碼的內容。它沒有給讀者提供代碼的附加信息。
代碼的解釋
解釋性註釋，典型地用於解釋複雜的，有效的和靈敏的代碼段。這種情況下，他們是有用的，但常常是由於代碼是易混淆的。假如代碼複雜到需要解釋，那麼改進代碼總比增加註釋更好些。使代碼本身清晰，然後使用總結或註釋。
代碼中的標記
標記註釋並非是故意留在代碼中的註釋。它是給開發者的記錄，表示工作還未做。一些開發者的標記註釋爲語法錯誤的標記（例如**），因而編譯程序標記它並提醒他們要做更多的工作。其它開發者把一套特殊字符放人註釋中，因而他們可以發現它們，但編譯程序不能識別它們。
代碼的總結
總結代碼的註釋做法是；它簡化一些代碼行成一或兩句話。這樣的註釋比起僅重複代碼而使讀者比讀代碼更快的那種註釋更有價值了。總結註釋是相當有用的，特別是當其它人但不是代碼的編者試圖修改代碼時。
代碼意圖的描述
意圖這一層上的註釋，解釋了代碼的目的。意圖註釋在問題一級上，而不是在答案一級操作。例如：
｛get current employee information｝獲取當前僱員的信息
是一句意圖註釋，而
｛update Employee structure ｝修改僱員記錄結構
是一句利用答案的總結描述。在 I BM六個月的學習，發現編程員最常說“理解最初的編程意圖是最難的問題”（Fj el st ad 和 Haml en 1919）。意圖註釋和總結註釋的區別不總是清楚的，但常常這不是重要的。意圖註釋的例子本章始終都給出了。
爲全部代碼接受的註釋僅是意圖和總結註釋。
有效註釋不是時間的浪費。太多註釋和沒有註釋一樣糟糕。你可採取一個合理的中間數量。
由於兩種共同的原因，註釋要花費許多時間去寫。第一，註釋可能會浪費時間或令人厭煩——脖子疼痛。假如這樣，重寫一個新的註釋。需要許多繁重工作的註釋是很令人頭疼的。假如註釋難於改變，他們就不必改變了；不準確和錯誤註釋比根本沒有註釋更糟糕了。
第二，用語言描述程序做什麼並不見得容易，所以註釋會更難些。這常是你並不瞭解程序做什麼的標誌。你花在註釋上的時間，應更好理解程序的真正時間，那是不管你是否註釋都要花費的時間。
使用風格不應打斷或妨礙修改
任何太具想象力的風格都會妨礙維護。例如，選取下面的註釋部分將不便維護：
難以保存的註釋類型的 Fort ran例子：
C 變量 含義
C …… ……
C XPOS..... X 座標位置（以米爲單位）
C YPOS..... Y 座標位置（以十爲單位）
C NPCMP..... 計算標誌（=0 若不需要計算，
C =1 若需要計算）
C PTGTTL.... 合計
C PTVLMX.... 最大值
C PSCCRMX.... 最大可能的值
假如你說這些起頭的園點（⋯⋯）將難以維護，那麼你就對了！他們看起來很好，但沒有他們會更好些，他們將對修改註釋的工作增加負擔，你寧願有準確的註釋而不是好看的註釋，假如有這種選擇的話——常常是這樣的。
下面是另一個難以維護普通風格的例子：
C語言的難以維護的註釋風格的例子：
/* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* 模型：GIGATROM.C *
* 作者：Dwight K.coder *
* 時間：2014 年 7 月 4 日 *
* *
* 控制二十一世紀程序的代 *
* 碼開發工具。這些程序的 *
* 入口點在這個文件的底部的 *
* 行, 程序名爲 Evaluatecode() *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
這是一個好看的註釋塊。很清楚，整個塊自成一體，並且塊的開頭和結尾都很明確。對這個塊還不清楚的是它變化起來是否容易。假如你必須在註釋底部增加文件名，那麼你對右邊漂亮的星號欄的就得重新編輯。假如你想要改變這段註釋，那麼你就要去掉左邊和右邊的星號。實際上這意味着這個塊不便維護，因爲要做比較多的工作。假如你按一個鍵便可得到幾列整齊的星號，那就太好了。不要使用它，他們難以維護的問題不僅是在星號上面。下面的註釋看起來並不好，但它肯定便於維護：
便於維護的 C語言的註釋風格例子：
/* * * * * * * * * * * * * * * * * * * * * * * * * * * *
模型：GIGATRON.C
作者：Dwight K.Coder
日期：2014 年 7 月 4 日
控制二十一世紀程序的代碼
開發工具。這段程序的人口
在文件底部，程序名爲 EvaluateCode()
* * * * * * * * * * * * * * * * * * * * * * * * * * * * */
下面有一個極難維護的風格：
難於維護的 Basi c 語言的註釋風格例子：
設置顏色枚舉類型
+——————————————————+ ．．．設置菜單枚舉變量
+——————————————————+ ．．．
很難知道註釋裏破折號行起始和結尾的加號其值是多少？但容易猜出每次註釋的變化，下劃線不得不調整以使得結尾的加號處於正確的位置。當一個註釋行被分成兩行時你將如何辦呢？你將怎麼安放加號？去掉註釋裏的文字以使得它僅佔據一行嗎？使兩行具有相同的長度？當你試圖不斷應用它時，這種辦法的問題會很多。
關鍵點是應注意如何去分配你的時間。假如你花費了大量時間增加和刪除破折號以使得加號對齊，你就無法編程了，而且是在浪費時間。找一個更有效的方式。在用加號下劃線的情況中，可以進行選擇，使得註釋沒有任何下劃線。假如你需要使用下劃線來強調，就找別的方法，而不用加號來對註釋進行強調。一種辦法就是用一個標準的下劃線，不管註釋的長度它都一樣長。這樣的線不需要維護，你可在開始位置用一個文字編輯宏來定義它。
使用 PDL編碼過程來減少註釋時間
假如寫代碼前你勾劃了註釋中的代碼，便可通過幾種方法實現。當你完成了代碼，註釋也就完了。在你填寫低層的程序語言代碼前，你可以獲得高層 PDL。
在你進行過程中註釋
寫代碼時，可以選擇註釋，直到工程結束再停止註釋，這樣做有很多的優點。在它自己的權限內，這變成了一項任務，使得看起來比每一次做一點時更有效率。以後再註釋會花費更多的時間，因爲你必須記住或算出代碼在做什麼而不是在書寫你已想好的東西。因爲你可能已忘記了設計中的假設和細節，所以這樣也不會準確。
反對在進行編程時註釋的觀點認爲“當你集中精力寫代碼時，不應當分散精力去寫註釋”。正確的答案是，假如你極其用心地寫代碼，註釋會打斷你的思路，你需要先設計 PDL，然後把PDL 轉化成註釋。需要集中精力編代碼是一個警告信號，假如你的代碼很難，在你對代碼和註釋擔憂前應簡化它。若你使用 PDL分類你的想法，編碼是直接的而註釋是自動的。
最佳數量的註釋
工程有時採用一個標準，比如“程序必須至少每五行便有一行註釋”。這個標準說明了程序員未寫清晰代碼的特徵，且未指出原因。
若你有效地使用 PDL 編碼過程，最後你會得出結論：第幾行代碼就要有一行註釋。然而，註釋的數量對過程本身來說是副作用。不能集中在註釋的數量上，而是要集中是否每條註釋都有效。假如明白了爲什麼寫註釋以及清楚了本章中涉及的其它法則，你就會有足夠的註釋了。