在C++代碼中使用C風格的註釋是不好的做法嗎？

Question

在閱讀this維基百科條目約doxygen，我遇到了這樣的說法：

很多程序員避免使用C風格的註釋，而使用C++ 風格的單行註釋。

這是正確的嗎？如果是這樣，爲什麼呢？這只是一種習慣，還是背後有一些技術和理性的原因？從上述文章

---

例子：

/** 
* <A short one line description> 
* 
* <Longer description> 
* <May span multiple lines or paragraphs as needed> 
* 
* @param Description of method's or function's input parameter 
* @param ... 
* @return Description of the return value 
*/ 

與

/// <A short one line description> 
/// 
/// <Longer description> 
/// <May span multiple lines or paragraphs as needed> 
/// 
/// @param Description of method's or function's input parameter 
/// @param ... 
/// @return Description of the return value 

Answer 1

C風格評論/* */不能遞歸嵌套。將多個單行註釋疊加在一起，就像這個'//////'一樣，不是問題。通過這種方式，您可以強制註釋掉部分代碼。 Visual Studio舉例來說支持這種功能來增加/減少這種方式的評論級別的數量。

A贊成'/ * * /' - 風格的評論是使特殊類型的評論脫穎而出當滾動代碼，如方法文檔。這也爲代碼創建了一個很好的視覺結構。

的「/ * * /」註釋的另一用例是那種具有代碼雙方，如void myfunc(double size /* = 0 */) { ... }，使默認值在cpp文件可見內部註釋。

一種可能的方法來兩個好處結合起來是：

• 使用 '//' 裏面的方法（其中ou想在評論/我們的反覆發作）和
• 僅使用 '/ * * /'對於特殊類型的評論，例如cpp中的doxygen文檔。

Answer 2

這完全是對什麼是可以接受的風格問題 - 有使用一種風格，不是沒有技術原因另一種語言（除非你有一個非常老的編譯器）。

一些社區會希望在一個風格的註釋 - 例如，Linux內核（一個C社區）會想到空調風格評論，但內核源快速的grep顯示了一些C++風格的註釋已經使它

。所以，如果你正在爲一個項目做出貢獻，那麼你應該符合那裏已經使用的風格。如果你是單獨工作或類似的工作，你可以使用你喜歡的東西 - 儘管最好不要混合風格。

Answer 3

現在有沒有既不空調風格的意見，也沒有C++風格的註釋，因爲C和C都++支持兩種類型的評論， 所以在一條線上的到底是更好地使用//註釋而長塊當使用/ * .. * /註釋時，評論更具可讀性。

至於我我通常更喜歡使用/ * ..* /註釋，用於在函數定義或聲明之前放置的函數的一般描述。如果我需要在一些代碼片段中添加一條評論，並且只需要插入一行評論，我就可以使用//評論。

Answer 4

我認爲這確實是一個口味問題。

有許多約定，只要有多個選項可用，總會有討論。這同樣適用於匈牙利與非匈牙利命名法，蛇形情況VS駝峯等

一般而言，這取決於幾個因素：

1）什麼是可以接受的風格。 如果你在大型項目中工作，你通常必須（也應該）服從編碼風格的一般規則。在同一個項目的不同文件中有不同的評論風格是非常不希望的。

2）大部分團隊喜歡什麼。 應該討論接受的約定以適應開發人員的偏好。應該沒有壓力 - 只要大家都認爲一切都很好。

3）什麼是技術要求。 如果你需要某種形式的嵌套，你應該仔細考慮。多行註釋不能嵌套。在下面的順序：

 
/* -> 1 start 
/* -> 2 start 
*/ -> 2 end 
*/ -> 1 end 

「2啓動」不會被識別爲註釋，「2月底」將成爲比賽的「1點開始」和「1點結束」會引發編譯器錯誤。

4）當應該使用特定評論時。 在創建類的一般描述時（例如），可能需要使用/ * * /創建多行，強烈描述的註釋。在部分代碼中插入簡短描述（單個表達式，方法參數描述或附加註釋）時，簡單的單行註釋（//）可能是一個更好的主意。

另外，值得一提的是，ML評論被假定爲多行。是什麼意思：在Visual Studio中，例如，創建文檔註釋後：

 
/** 
* 
*/ 

星號（*）將被添加按評論進入裏面後自動，讓您創建沒有好看的評論額外的工作：

 
/** 
* Some nice description [pressing enter here] 
* //-> this was inserted by editor 
*/ 

如果多行註釋使用單行標記（//），則需要手動在每行添加它們。

有一種情況，您應該使用單行註釋：使用Visual Studio。我的意思是什麼？ VS有一個很好的功能來評論/取消註釋一段代碼。這些任務有特殊的快捷方式 - Ctrl-K，Ctrl-C用於註釋，Ctrl-K，Ctrl-U用於取消註釋。現在，編輯器會檢查應該使用什麼樣的評論：

void f() 
{ 
    int p = 0; 
    int k = 0; 
    while(true) { 
    ++p; 
    ++k; 
    } 
} 

讓我們的評論整個函數[按Ctrl-K-C ...]。結果如下：

//void f() 
//{ 
// int p = 0; 
// int k = 0; 
// while(true) { 
// ++p; 
// ++k; 
// } 
//} 

讓我們評論while body並使其爲空[按Ctrl-K-C ...]。這是結果：

void f() 
{ 
    int p = 0; 
    int k = 0; 
    while(true); /*{ -> comment was invoked inside the line, multiline is required. 
    ++p; 
    ++k; 
    }*/ 
} 

它時，你預計使用單行註釋，該代碼的某些部分可以從源代碼被暫時排除是非常重要的。我們認爲，如果我們同時的身體包含註釋，會發生什麼：

1）第一種情況，SL評論：

//void f() 
//{ 
// int p = 0; 
// int k = 0; 
// while(true) { 
// ++p; //some comment -> ok, '//' can be nested 
// ++k; 
// } 
//} 

2）第一種情況，ML評論：

//void f() 
//{ 
// int p = 0; 
// int k = 0; 
// while(true) { 
// ++p; /*some comment*/ -> ok, '/**/' can be nested inside // 
// ++k; 
// } 
//} 

3）二情況下，SL評論：

void f() 
{ 
    int p = 0; 
    int k = 0; 
    while(true); /*{ -> comment was invoked inside the line, multiline is required. 
    ++p; //some comment -> ok, '//' can be nested inside multiline 
    ++k; 
    }*/ 
} 

4）第二種情況，ML評論：

void f() 
{ 
    int p = 0; 
    int k = 0; 
    while(true); /*{ -> comment was invoked inside the line, multiline is required. 
    ++p; /*some comment*/ 
    ++k; 
    }*/ -> oh.. 
} 

由於SO使用相同的規則解析註釋，因此應該看到最後一個示例中的最後一個標記不會變灰。從我的角度來看，這是一件很重要的事情，因爲我經常使用塊（un）評論。