的Bug數量評論

Question

你爲什麼要添加

//錯誤1024

註釋到源控制的代碼庫？ 大多數的錯誤跟蹤和源代碼管理系統都能更好地跟蹤這些信息。 在源代碼控制中，標籤或註釋可以與簽入一起使用。在錯誤跟蹤器中，可以將修訂號添加到錯誤的分辨率中。那麼爲什麼要評論代碼？特別是因爲這些評論相關性非常短暫，他們傾向於積累亂拋垃圾的代碼庫。

Answer 1

我發現其中一個在我們的代碼庫有用的那天。

我說「爲什麼他第二次調用初始化函數，這在工作流的最後階段??」

該錯誤評論讓我去正確的問題描述。當我重新編寫代碼時，我肯定會將該錯誤包含在我的測試中，而不是重新引入它。

雖然我會說，一般來說，我同意你的觀點，不要自己插入。

我更希望有問題的開發人員以更有意義的方式修復了這個錯誤，這樣我就不必首先想到代碼了。

Answer 2

純粹的懶惰。當然，從長遠來看需要更多時間，但在短期內「// Bug 1024」無論如何都不費吹灰之力。你擁有的代碼越多，這就越糟糕。

Answer 3

最終，我認爲這是一個不好的做法。最好包括錯誤存在的原因（類型Y的fo不具有屬性Z）。如果需要，可以在「BugId 12345」中加入「更多內容」。

如果您在多個級別上進行集成，trac中的源代碼視圖可以直接鏈接到BugId。

Answer 4

我這樣做直到Visual Studio 2008附帶註釋。當回顧舊代碼時，立即看到至少有一個特定的代碼決策背後有過思考，這很有用。

是的，我知道你可以和以前的版本做比較，但是如果你只需要一些簡短的代碼更新的快速感受，就會感到很痛苦。

Answer 5

想象一下，您有一個新的錯誤，可以追溯到修訂版12345中的更改。您查看日誌，它會立即告訴您Bug 1024是進行更改的原因。

然後，您可以去看看1024年，看看在做出新修正之前是什麼，爲什麼以及什麼時候 - 「統治所有人」。

如果錯誤編號不在提交消息中，那麼您必須搜索提交修復的錯誤 - 這可能是幾個錯誤（如果錯誤報告不止一次）。

Answer 6

我同意你的看法，這不是真的有用，而且太簡短了。

然而，它是非常有用和重要的，以引用缺陷跟蹤系統中的記錄（或擴展到您可能擁有的任何知識庫）來評論代碼。

有時一個代碼更改實施規避一定的問題與應用程序的行爲。有時候，引入的解決方法絕不合邏輯。經常發生的情況是，當代碼被其他人更新時，這個「壞」的代碼片段被作爲重新分解工作的一部分被移除。

所以，標誌着代碼屬於特定漏洞修復，使再保期間，可見，促使開發商改變代碼之前查看錯誤描述。它還有助於在錯誤重新打開的情況下 - 如果您不得不多次更改代碼的相同部分，您可能會考慮將時間投入到替代解決方案中。

P.S.你可以考慮從Joel On Software的關於MS Office的文章this。據我所知，MS Office和MS Windows的代碼充滿了類似的評論，這些評論解釋了開發者早已離開的決定。

Answer 7

我覺得它有用解釋代碼，否則似乎錯的時候，也用在提交信息。

Answer 8

如果通過不熟悉的源代碼瀏覽，和你看到的東西不明顯，這是很好的知道原因。這是一個判斷電話，但並非每一個錯誤修復都需要這樣的解釋 - 如果沒有它，大多數情況下都可能逃脫。

Answer 9

我認爲這是一個「我有錘子，一定是釘子」的情況。您的文本編輯器或IDE不是管理代碼的唯一工具。

歷史最好在代碼的外部維護。代碼的含義應該在註釋中描述，但不能立即顯現。

我同意bug數應該在源控制提交消息中。

Answer 10

我不這樣做。我想不出爲什麼你會在代碼中放入缺陷ID。我將把它放在發行說明/更新日誌上。

我真正有用的是使用缺陷ID作爲自動化測試的名稱的一部分：

[TestFixture] 
public class Release_1_2_Bugfixes 
{ 
    [Test] 
    public void TestBug42() 
    { 
    Assert.AreEqual(42, CalculateAnswerToLifeUniverseAndEverything()); 
    } 
} 

我見過other projects做同樣的事情。

Answer 11

如果有足夠的理由相信有人想在查看部分代碼時想知道錯誤號，那麼添加一個提及該錯誤的註釋可能會相當不錯（希望它能夠解釋錯誤的重要部分）但是）。

是的，源代碼控制提交信息中還應該包含錯誤號碼，並期待通過修改日誌可以給你同樣的信息......但如果代碼的同一部分被多次更改，但在細節上了解到，從最初的錯誤仍然適用，可能需要一段時間才能找到原始更改以瞭解該錯誤。

此外，當有充分的理由將代碼從一個類移動到另一個類或重命名文件時會出現這種情況，這會使得更難找到某段代碼背後原因的根源（不重命名如此多的SVN問題，但與CVS的痛苦）。

Answer 12

你不應該只添加錯誤號。您應該添加的bug數量和對象，以及任何限定詞，如果你做了一個錯誤多籤：

錯誤1111 - 美孚搗毀的64位系統。修復＃2，因爲它在合併到主幹後重新打開。

某些系統具有錯誤號集成。在mxr.mozilla.org中，CVS日誌顯示中的錯誤編號會自動變成鏈接到bugzilla.mozilla.org編號的鏈接。當你在代碼中挖掘，這是一個巨大的時間段。我認爲Fogbugz有一個類似的功能...

另外，即使你的系統沒有，它通常也是有幫助的，因爲沒有人想看到整個上下文的變化，這就是bug追蹤器的用處。

Answer 13

你碰到了一個問題：「相關性非常短暫，他們傾向於積累垃圾代碼庫。」

構建在源文件中的每一點無用信號都使得它們不易讀，難以維護。刪除沒有增加價值的所有內容。 「Bug 12345」現在幾乎沒什麼價值，幾周後就沒有了。

Answer 14

我們在一個大型系統上工作，有許多開發人員和多個分支機構。

這些錯誤引用註釋在從一個分支移植到另一個分支時實際上非常有用，特別是因爲我們使用的SCM系統功能很差，提交註釋很難獲得或可能會很老。

如果修復很簡單，那麼它可能不需要錯誤標記。如果它不明顯，那麼引用一個Bug可能更有意義，然後在評論部分寫一個長的解釋。

Answer 15

我不喜歡這種塗鴉。像其他不合時宜的生活形式一樣，它們隨着時間的流逝而增加，窒息了代碼庫。

當人們進行錯誤修復時，麻煩真的開始了，這些錯誤修復重疊了以前的錯誤修復。然後你有bug編號標記了一段簡單的錯誤或誤導的代碼。

Answer 16

我很驚訝有多少人反對這一點。我個人對此的感覺是，這是一個很好的想法想法。我同意早先的評論，它應該不僅包括錯誤編號，並且最好包括一個簡短的摘要和鏈接到錯誤跟蹤系統（如果適用的話）。

這些評論的好處只在具有歷史記錄和大量以前的錯誤修復的較舊項目中顯而易見。您無需在任何地方發表這些評論，但是將它們放置在可能沒有上下文無關的代碼塊之前時非常有用。在任何一種相當複雜的系統中，都會出現代碼片段，這些代碼在沒有上下文的情況下似乎不合邏輯或不必要。

由於與系統或舊的解決方法的交互，代碼是必要的。爲了防止某個人稍後重新引入補丁錯誤，指出代碼塊旨在修復的錯誤非常有用，最好附帶一些類型的解釋。否則，你會依賴於某人在提交日誌中仔細檢查提交歷史記錄的原因，這是非常不可能的，特別是如果某人正在重構代碼。

編輯：我特指將這些代碼與不尋常的代碼塊或需要額外的上下文。對你所做的每一個錯字修改都沒有意見或建議:-)

Answer 17

這種類型的評論IS非常有幫助：當你改變錯誤跟蹤或源代碼控制工具時會發生什麼？對BZ1722與FB3101的引用會告訴你需要檢查的跟蹤工具（例如Bugzilla或FogBugz）。

Answer 18

這是一件好事！

誰在看代碼的人是不可能體會到代碼的完整歷史，並有可能撤銷一個非常重要的變化，因爲他們可能沒有這方面的代碼的工作之前。它可以解釋代碼，否則看起來瘋狂或客戶的要求相當離奇。

你不能總是通過架構和代碼捕捉客戶需求的具體的，特定，尤其是當他們問一些愚蠢的事。因此，你開始懂事，然後提煉或代碼攻入愚蠢時，你不得不這樣做，這個bug數備份瘋狂代碼的意圖。