編寫代碼注釋的最佳實踐

時間：2021-11-08 15:55:15

關(guān)鍵字：代碼編寫

手機看文章

掃描二維碼
隨時隨地手機看文章

[導(dǎo)讀]關(guān)注、星標(biāo)公眾號，直達精彩內(nèi)容來源：CSDN（ID：CSDNnews）作者：EllenSpertus|?譯者：王雪迎??雖然有很多資源可以幫助程序員編寫更好的代碼，比如書籍或靜態(tài)分析器，但是很少有資源可被用于編寫更好的注釋。雖然度量一個程序中的注釋數(shù)量很容易，但衡量注釋的質(zhì)量卻很...

雖然有很多資源可以幫助程序員編寫更好的代碼，比如書籍或靜態(tài)分析器，但是很少有資源可被用于編寫更好的注釋。雖然度量一個程序中的注釋數(shù)量很容易，但衡量注釋的質(zhì)量卻很難，而且兩者并不一定相關(guān)。差的注釋比根本不寫注釋更糟糕。這里有一些規(guī)則可以幫助你實現(xiàn)一種折中的方法。

麻省理工學(xué)院的著名教授Hal Abelson曾說過：“程序必須寫給人們閱讀，而只是附帶地讓機器執(zhí)行?！彪m然他可能故意低估了運行代碼的重要性，但卻注意到了程序有兩種截然不同的受眾。編譯器和解釋器會忽略注釋，找出同等容易理解的所有語法正確的程序。而人類讀者則完全不同。我們發(fā)現(xiàn)有些程序比其它的更難理解，此時就會通過查看注釋來幫助我們理解這些程序。

雖然有很多資源可以幫助程序員編寫更好的代碼，比如書籍或靜態(tài)分析器，但是很少有資源可被用于編寫更好的注釋。雖然度量一個程序中的注釋數(shù)量很容易，但衡量注釋的質(zhì)量卻很難，而且兩者并不一定相關(guān)。差的注釋比根本不寫注釋更糟糕。正如Peter Vogel所述：

編寫并維護注釋是一項開銷。
編譯器不會檢查注釋，因此無法確定注釋是否正確。
另一方面，你可以保證計算機完全按照你的代碼所示運行。

所有這些觀點都是正確的，但如果走到另一個極端，即從不寫注釋，那將是一個錯誤。這里有一些規(guī)則可以幫助你實現(xiàn)一種折中的方法：

規(guī)則1：注釋不應(yīng)與代碼重復(fù)。
規(guī)則2：好的注釋不能成為代碼不清晰的借口。
規(guī)則3：如果無法寫出一個清晰的注釋，代碼可能有問題。
規(guī)則4：注釋應(yīng)該消除混亂，而不是引起混亂。
規(guī)則5：在注釋中解釋不規(guī)范的代碼。
規(guī)則6：提供復(fù)制代碼的原始出處鏈接。
規(guī)則7：在可能提供幫助的地方引入指向外部參考的鏈接。
規(guī)則8：在修復(fù)bug時添加注釋。
規(guī)則9：使用注釋來標(biāo)記未完成的實現(xiàn)。

本文其余部分將逐條解釋這些規(guī)則，提供示例并說明如何以及何時應(yīng)用它們。

規(guī)則1：注釋不應(yīng)與代碼重復(fù)

許多初級程序員會寫太多注釋，因為他們接受了入門指導(dǎo)老師的培訓(xùn)。我曾見過計算機科學(xué)系的高年級學(xué)生為每對大括號加上一條注釋，以表示該塊結(jié)束：

if (x > 3) { …} // if 我也聽說過老師要求學(xué)生對每一行代碼進行注釋。雖然這對極為初級者來說可能是一個合理的策略，但這樣的注釋就像是訓(xùn)練輪，在大孩子騎車時應(yīng)該去掉。

不添加任何信息的注釋具有負價值，因為它們：

增加視覺混亂
讀寫花時間
可能會過時

一個典型的壞示例為：

i = i 1; // Add one to i 它不添加任何信息，并切產(chǎn)生維護成本。

每一行代碼都需要注釋的策略在Reddit上都受到了相當(dāng)?shù)某靶Γ?/span>

// create a for loop // <-- commentfor // start for loop( // round bracket // newlineint // type for declarationi // name for declaration= // assignment operator for declaration0 // start value for i

規(guī)則2：好的注釋不能成為代碼不清晰的借口

注釋的另一個誤用是提供本應(yīng)包含在代碼中的信息。一個簡單的例子是，有人用一個字母命名一個變量，然后添加一個描述其用途的注釋：

private static Node getBestChildNode(Node node) { Node n; // best child node candidate for (Node node: node.getChildren()) { // update n if the current state is better if (n == null || utility(node) > utility(n)) { n = node; } } return n;} 通過更好的變量命名，可以不需要再做注釋：

private static Node getBestChildNode(Node node) { Node bestNode; for (Node currentNode: node.getChildren()) { if (bestNode == null || utility(currentNode) > utility(bestNode)) { bestNode = currentNode; } } return bestNode;} 正如Kernighan和Plauger在編程風(fēng)格要素一書中所寫，“不要注釋糟糕的代碼 — 重寫它?！?/span>

規(guī)則3：如果無法寫出一個清晰的注釋，代碼可能有問題

Unix源代碼中最臭名昭著的注釋是“你不希望理解它”，它出現(xiàn)在一些恐怖的上下文切換代碼之前。Dennis Ritchie后來解釋說這是故意為之：“本意是想表達‘這不會出現(xiàn)在考試中’，而不是作為一種厚顏無恥的挑戰(zhàn)?！辈恍业氖?，結(jié)果發(fā)現(xiàn)他與合作者Ken Thompson自己也理解不了，后來不得不重寫。

這讓人想起了Kernighan定律：

調(diào)試在一開始就比編寫程序困難一倍。因此，按照定義，如果你的代碼寫得非常巧妙，那么你就沒有足夠的能力來調(diào)試它。

警告讀者遠離你的代碼就像打開汽車的危險警示燈：承認(rèn)你正在做知法犯法的事情。相反，把代碼重寫成你充分理解的東西，或者更進一步，直截了當(dāng)?shù)剡M行解釋。

規(guī)則4：注釋應(yīng)該消除混亂，而不是引起混亂

如果沒有Steven Levy的黑客：計算機革命的英雄中的這個故事，任何關(guān)于負面注釋的討論都是不完整的：

[Peter Samson]拒絕在源代碼中添加注釋來解釋他在特定時間所做的事情，使其特別晦澀難懂。在一個分發(fā)良好的程序中，Samson繼續(xù)編寫了數(shù)百條匯編語言指令，其中只有一條包含1750數(shù)字的指令帶有注釋。注釋是RIPJSB，人們絞盡腦汁研究它的含義，直到有人發(fā)現(xiàn)1750年是巴赫去世的那一年，而Samson寫的注釋是Rest In Peace Johann Sebastian Bach（安息吧，約翰·塞巴斯蒂安·巴赫）的縮寫。

雖然我和別人一樣欣賞一個好的黑客，但這種注釋不可效仿。如果你的注釋引起混亂而不是消除混亂，刪除它。

規(guī)則5：在注釋中解釋不規(guī)范的代碼

注釋掉其他人可能認(rèn)為不需要或冗余的代碼是個好主意，比如來自App Inventor的代碼（我所有的正面示例均源于此）：

final Object value = (new JSONTokener(jsonString)).nextValue();// Note that JSONTokener.nextValue() may return// a value equals() to null.if (value == null || value.equals(null)) { return null;} 如果沒有注釋，有人可能會“簡化”代碼或?qū)⑵湟暈橐粋€神秘但必不可少的咒語。寫下為什么需要這些代碼，可以節(jié)省未來讀者的時間并解除他們的焦慮。

需要對是否注釋代碼做出判斷。在學(xué)習(xí)Kotlin時，我遇到了Android教程中的代碼：

if (b == true) 我立即想到是否可以用以下代碼取代：

if (b) 就像在Java中一樣。經(jīng)過一點研究，我了解到可以為null的布爾變量會顯式地與true進行比較，以避免出現(xiàn)難看的null檢查：

if (b != null