我注意到，看示例代碼的片段（如下面），大多數使用獨佔多行/ * * /註釋，而不是單行//註釋。爲什麼是這樣？爲什麼很多示例在c/C++中只使用多行註釋？
http://www.freertos.org/RTOS_Task_Notification_As_Event_Group.html
我一直覺得這是一個有點討厭，因爲它阻止我如果有必要註釋掉的代碼塊，即當你複製的碼位到一個新的項目，並沒有但更新了所有相關功能以在新項目中編譯。
我發現的唯一信息是，平臺之間如何處理新行可能存在問題，某些系統可能無法正確解釋新行以結束單行註釋。這是唯一的原因嗎？這些示例遵循的是否有一些樣式指南禁止單行註釋？
您使用FreeRTOS教程作爲C++的示例。如果你看看FreeRTOS的sources，你會發現它實際上是用C編寫的，而不是C++。
在C語言中引入C風格的單行註釋（//）之前並不存在於C語言中。很多代碼，包括教程，都是在C99之前編寫的。甚至可以編寫新的C代碼而不使用新的語言功能，以保持程序與不支持新規範的較舊編譯器兼容 - 或僅僅由於舊習慣或偏好。
我一直覺得這是一個有點討厭，因爲它阻止我如果有必要
使用此註釋掉的代碼塊臨時禁用的代碼塊：
#if 0
/* Bits in this RTOS task's notification value are set by the notifying
tasks and interrupts to indicate which events have occurred. */
xTaskNotifyWait(0x00, /* Don't clear any notification bits on entry. */
ULONG_MAX, /* Reset the notification value to 0 on exit. */
&ulNotifiedValue, /* Notified value pass out in
ulNotifiedValue. */
portMAX_DELAY); /* Block indefinitely. */
#endif
通常它與編碼標準有關。標準是一種書寫習慣（在羣體/計算機語言/公司之間），旨在使代碼更具可讀性，並使其看起來像是單個編碼人員完成的（標準目標）。並非所有公司都有相同的標準，但freertos使用/ * * /（和Google例如使用//）。
這就是您爲我們標記的代碼擁有這些/ * * /的主要原因，因爲這就是公司如何編寫它的代碼所達成的共識。
_「使它看起來像是一個單一的編碼人員寫的（標準的目標）。」_不，編碼標準故意承認代碼是由多人/多人編寫的;我們的目標是確保他們都可以使用通用的「語言」來理解彼此的代碼。 –
這個答案無論如何都是空的。它只是把目標移到「好吧，好吧，爲什麼是公司的編碼標準？」 –
你不能要求_why_約定，因爲約定是某人決定的。編碼標準的主要目標是讓它看起來像是一個單獨的編碼器寫的，這增加了可維護性並降低了複雜性。如果代碼看起來像是由幾個人編寫的，那麼代碼可能沒有任何標準。 –
兩條單行註釋//和多行註釋/* */都是有效的C++。爲什麼有人使用這種方式純粹是品味和個人喜好的問題。
如果你有一個體面的文本編輯器，例如Emacs，標記塊評論，然後做M-x comment-region或類似的其他編輯器/ IDE，它們都不會阻止你評論代碼塊，他們會做正確的事情。如果不;得到一個更好的編輯器/配置爲您的當前編輯器。
要描述一個程序我們在開始時編寫的東西我們通常使用/ * * /因爲它可以通過多行並描述特定的行什麼和它的功能//
您正在查看的代碼很可能是或最初是在C中編寫的。除此之外，編碼只是一種風格選擇，也可能是這個項目的主角選擇了這種風格。有兩種方法來解決這個問題：
#if 0
#if 0
some code we hate
#endif
OR
如果您使用的是IDE，它很可能，他們必須註釋掉的代碼塊的選項：
導致此：
// stuff;
// stuff;
// stuff;
對於多行註釋來說，這很容易。使用// vs/* * /僅僅是一種沒有正確技術的樣式選擇 –
很長一段時間'''''''''''* /''是所有可用於便攜式C的類型。因此，舊的C程序員更可能選擇這種形式。請注意，在你的例子中'＆ulNotifiedValue'是一個C風格的超參數。 –
不確定爲什麼你標記爲C++？ FreeRTOS是用C編寫的。 –