記錄類和接口的最佳實踐是什麼？假設你有一個名爲Foo的具體類，它來自一個名爲IFoo的接口。你在哪裏爲你的方法提出你的評論？你是否在界面以及具體的課程上重複你的評論？代碼註釋：你是否將代碼註釋放在接口或混凝土類上？
這裏是註釋重複的一個例子：
public class Foo : IFoo
{
/// <summary>
/// This function does something
/// </summary>
public void DoSomething()
{
}
}
public interface IFoo
{
/// <summary>
/// This function does something
/// </summary>
void DoSomething();
}
我會把意見上都在想工具提示。
在接口上，我會評論接口成員和用法背後的意圖。
關於實現，我會評論具體實現的原因。
我一般把他們兩個，但是，他們不說同樣的話。接口的評論應該描述這個方法/接口的抽象目的。雖然具體的評論將在接口的目的上下文中討論方法/類的實現細節。
我把它們都放在了它們中間，但是它讓我們很難保持同步，當有疑問時我只把它們放在界面上。
我這樣做是因爲我使用的代碼，這應該總是使用界面......
我根本沒有使用它們。相反，我確保構建代碼並以一種明顯的方式命名所有的方法和變量，而不需要評論。註釋的問題在於它們不會編譯，也不會執行，並且未經過單元測試的測試，所以幾乎不可能讓它們與代碼保持同步。
這些註釋更多的是用於Intellisence，然後用於理解代碼。我同意他們很難維護，但他們可以非常有助於探索API。 – 2009-12-09 17:30:52
嘿，我想他們在爲另一個團隊的人開發API時非常有用。 – Grzenio 2009-12-09 17:35:50
僅適用於接口。因爲在這種情況下我不需要同步它們。我的IDE幫助我在具體的類中看到接口註釋。而api文件生成器也是這樣。
兩個，但我希望能有內置的功能來保持同步
你的示例代碼不使用顯式接口實現。您的代碼的客戶端將需要兩者，因爲他/她可以通過類對象或接口引用來調用該方法。通過顯式的接口實現，您可以省略類方法註釋，因爲客戶端永遠無法看到它。假設您使用XML文檔來生成IntelliSense信息。
的標籤<referTo>System. .... </referTo>鏈接的評論將是理想的
理想的情況下，只需要記錄的接口，因爲它定義了每一個具體的實施需要履行合同。
+1 ...如果您使用的是GhostDoc，可以很容易地將從接口成員複製的接口註釋複製到其具體實現中。 – Groo 2009-12-09 18:14:37