我很感興趣，聽到的例程，您必須清理你 分發給客戶的公共的頭文件。準備公開頭髮布
有些事情，我想聽聽你的意見是：並不意味着外部消費
評論。一般來說，我喜歡保持文檔接近 的代碼和這樣的評論可能不是一個好主意分享到：
/**
* @todo Should we change the signature of this function to
* make it obvious that xxx is really yyy?
*/
或者是：
/**
* @todo Add support for feature X
*/
不一致的選項卡樣式：
void functionA(int a,
int b,
int c,
int d);
void functionB(int a,
int b,
int c);
有沒有用於準備發佈的標題或代碼的工具？
對於任何涉及多個開發人員的任何涉及多個開發人員的項目，在任何延長的時間段內以及隨後發佈的源代碼，掃盲對於OBSCENITIES（以及其他你不應該說的事情，例如「我的老闆讓我做這個「，」這個代碼很糟糕「等）。此外，拼寫檢查評論可能會有所幫助，因爲人們錯誤地拼寫單詞可能會影響您的可信度。
請確保您的標題不會生成任何編譯器警告。
它通常會更好，如果你有編碼標準/格式的文件，用戶將看到開發商自己跟隨時，他們首先創建代碼，讓你不花時間發佈之前清理代碼，比如現在。
此外，Visual Studio和其他一些IDE的有一個「自動格式化」選項，在這裏你可以設置一個樣式，將它應用到你的代碼（製表符，空格之類的事情）。我認爲這主要是你在這裏要求的。
我不是很熟悉的話題，但對於開源項目你經常在頭頂部的許可和版權聲明。這可以避免幾個司法問題。
天兒真好，
在C++中我喜歡用Handle-Body idiom從公共接口儘可能地分離的實施。
您還應該確保任何樣板，例如版權聲明是一致的並且是最新的，例如， 2008年發佈的代碼版權未到期。
可以跨所有的公共頭文件一致的命名規則，格式，佈局和一流的設計，否則它留下客戶的unprofesional印象。
確保有在頭文件中沒有「使用」的聲明。濫用「使用」dec可能會導致無意的副作用。
如前所述，請確保您的標題不會生成任何警告。
最後。確保你已經有了一些很好的API文檔來處理你的頭文件。
不要像誰提供了一個衆所周知的郵政編碼查找產品的公司。 C API的第一個版本附帶了基於Windows GUI版本的極少的文檔。頭文件只包含那些參數只有類型而沒有名字的函數。和沒有評論。
只有這樣，才能制定出什麼樣的功能其實根本是逆向工程提供了一個簡單的查找示例程序和反向工程了。
儘管如此，管理要做到這一點我救了BBC的兒童需要數萬英鎊，每年的因爲爲籌款包的地址更可能是正確的比前幾年之後！
在具有內部使用的頭經常和自動清理公共消費我的經驗是一個艱鉅的任務，絕對容易出錯。最終不一致的格式或不恰當的評論將不可避免地蔓延開來。
在很多情況下，你可能會更好過包裹一切都變成小而乾淨的界面，其頭部始終保持清潔和評價成爲可能;對該文件的修改應該經歷例如特別仔細的審查過程。
與刪除重要評論一樣重要的是添加必要的評論。你可能需要的東西補充：
總是有人（最好不止一個）通過標題尋找任何看起來不專業的東西。您可以先使用代碼格式化器和其他自動工具。
徵集意見，讓他們尋找任何不專業或暫定。糾正拼寫錯誤。確保它們是準確的。有一個標準的方式來格式化，並堅持下去。
檢查所有標識符名稱。他們應該符合風格指南，並以專業名稱命名。
確保所有必要的評論都在那裏。這包括頂部的版權和聯繫信息。提出一個記錄類和類的標準方法，並執行它。
基本上，從我的角度來看，您希望您的標題看起來像沒有創造力或幽默感的無人機制作的，但是誰是完全一致的（有點像CPA刻板印象）。 （這就像是要求你的開發者在客戶訪問辦公室時穿西裝一樣 - 如果他們沒有看到你的開發者真的喜歡什麼，那麼客戶會更開心。）
+1對於修復拼寫和猥褻行爲。我確信我不允許（分）有意識地認爲無法拼寫的人不能被信任寫出可靠的代碼。如果你不擅長拼寫，請找別人來看看。 – 2009-06-05 12:24:54
查看所有評論，以確保它們看起來專業。不要依賴任何類型的自動掃描。你不想讓你的顧客閱讀「我的老闆讓我這樣做」或「我希望這可以工作」這些東西，而不是猥褻。 – 2009-06-05 14:47:27
好點。猥褻是大紅旗，但還有其他一些可能同樣不好的事情。編輯答案以反映這一點。 – GWLlosa 2009-06-05 15:06:15