這篇文章是由José M. Aguilar在他卓越的博客中以西班牙語的形式首發，其后Timm Martin在獲得Aguilar先生的授權下，對該文章進行翻譯、修改，并且在DevTopics上發布。
以下13個小技巧可以使得你的代碼在長時間內依然能夠保持容易理解和維護。
1. 對不同級別的代碼進行注釋
對于不同級別的代碼塊，要使用統一的方法來進行注釋。例如：
* 對于每一個類，需要包含一段簡明扼要的描述，作者和上一次修改的時間
* 對于每一個方法，需要包含這個方法的用途，功能，參數以及返回結果
當你在一個團隊里面的時候，采用一套注釋的標準是非常重要的。當然，使用一種大家都認可的注釋約定和工具（例如C#的XML注釋和Java的Javadoc）在一定程度上能推動這項任務。
2. 使用段落注釋
首先把代碼塊分解成多個“段落”，每一個段落都執行單一的任務；然后在每一個“段落”開始之前添加注釋，告訴閱讀代碼的人接下來的這段代碼是干什么用的
// 檢查所有記錄都是正確的
foreach (Record record in records)
{
if (rec.checkStatus()==Status.OK)
{
. . .
}
}
// 現在開始進行處理
Context ctx = new ApplicationContext();
ctx.BeginTransaction();
. . .
3. 對齊注釋行
對于那些在行末寫有注釋的代碼，應該對齊注釋行來使得方便閱讀
const MAX_ITEMS = 10; // maximum number of packets
const MASK = 0x1F; // mask bit TCP
有些開發人員使用tab來對齊注釋，而另外一些人會用空格來對齊。由于tab在不同的編輯器和集成開發環境中會有所不同，所以最佳的方法是使用空格來對齊注釋行。
4. 不要侮辱閱讀者的智慧
要避免沒用的注釋，例如
if (a == 5) //如果a等于5
counter = 0 //把counte設為0
這不單把時間浪費在寫沒用的注釋上面，同時也在分散讀者的注意力。
5. 要有禮貌
應當避免沒有禮貌的注釋，例如“要注意一些愚蠢的用戶會輸入一個負數”，或者“修正由菜鳥工程師寫的愚蠢得可憐的代碼而導致的副作用”。這樣的注釋對于代碼的寫注釋的人來說并沒有任何好處，同時你永遠都不會知道將來這些注釋會被誰來閱讀，你的老板，一個客戶或者是剛才被你數落的愚蠢得可憐的工程師。
6. 直截了當
不要在注釋里面寫過多的廢話。避免在注釋里面賣弄ASCII藝術，寫笑話，作詩和過于冗長。簡而言之就是保持注釋的簡單和直接。
7. 使用統一的風格
有些人覺得注釋應該讓非程序員也能看懂。另外一些人覺得注釋需要面對的讀者只是程序員。無論如何，正如Successful Strategies for Commenting Code中所說的，最重要的是注釋的風格需要統一，并且總是面向相同的讀者。就自己而論，我懷疑非程序員是否會去讀代碼，所以我覺得注釋應該面向程序員來寫。
8. 在內部使用特殊的標簽
當你在一個團隊里工作的時候，采用一組一致的標簽能幫助不同的程序員溝通。例如，很多團隊會采用“TODO”標簽來表示一段尚未完成的代碼
int Estimate(int x, int y)
{
// TODO: implement the calculations
return 0;
}
標簽注釋并不會解釋代碼，它們尋求注意或者是傳遞信息。但是如果適當地使用這種技術，要記住跟進這段代碼并且完成該標簽傳遞的任務。
9. 在寫代碼的同時添加注釋
當你在寫代碼而且記憶猶新的同時就添加注釋。如果等到項目后期才添加注釋，會讓你事倍功半。“我沒有時間寫注釋”，“我的時間很緊迫”和“項目已經延遲了”，這些都是不寫注釋的常見借口。有些工程師覺最佳的解決方法是“注釋先行”。例如：
public void ProcessOrder()
{
// Make sure the products are available
// Check that the customer is valid
// Send the order to the store
// Generate bill
}
10. 把自己想象為注釋的讀者（事實上就是如此）
當你正在給代碼寫注釋的時候，不僅僅為日后維護你的代碼的開發者考慮，同時也設想一下如果自己就是注釋的讀者。Phil Haack曾經說過：
“一旦一行代碼被敲到文件中, 你就已經要開始維護那一行代碼了。”
所以，我們自己就是好（或者壞）注釋的第一個受益者（或者受害者）。
11. 更新代碼的時候要更新注釋
如果注釋沒有隨著代碼的修改而更新，那么這些注釋將是毫無意義的。代碼和注釋需要同步，否則注釋只會讓維護代碼的開發者更加痛苦。需要特別注意的是，一些重構的工具會自動更新代碼，但是卻沒有自動更新注釋，那么注釋就自然而然地過期作廢了。
12. 良好可讀性代碼是注釋的金科玉律
對于很多開發者來說，一個基本的原則就是：讓代碼自己描述自己。雖然有人懷疑這是由不喜歡寫注釋的程序員所倡導的一場運動，但是無需解釋的代碼有很大的好處，這些代碼更加容易理解甚至讓注釋變得沒有必要。例如，在我的文章Fluid Interfaces中就給大家展示了什么是清晰的無需解釋的代碼。
Calculator calc = new Calculator();
calc.Set(0);
calc.Add(10);
calc.Multiply(2);
calc.Subtract(4);
Console.WriteLine( “Result: {0}”, calc.Get() );
在這個例子里面，注釋就像是違反了第4條技巧那樣，變得毫無必要。要寫出可讀性好的代碼，你需要使用適當的命名方式（在經典的Ottinger’s Rules中有闡述），保證恰當的縮進，并且采用編碼風格指導。如果代碼不遵守這條技巧，那么注釋看起來就好像是為自己不好的代碼的寫道歉信一樣。
13. 跟你的同事分享這些技巧
雖然從第10條技巧中我們已經知道了自己就是好注釋的得益者，但是這些技巧對于所有的開發者來說都是很有幫助的，尤其是整個團隊都有相同共識的情況下。因此，大方地跟你的同事去分享這些技巧，讓我們寫出更加容易理解和維護的代碼。