我很想知道你清理公共头文件的常用程序 分发给客户。
我想听听你的意见的一些事情是：
评论不适用于外部消费。一般来说，我喜欢保持文档密切 这样的代码和评论可能不是一个好主意分享：
/**
* @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);
是否有任何工具可用于准备标题或代码以供发布？
答案 0 :(得分：15)
对于任何涉及多个开发人员的项目，你应该总是在任何延长的时间段内以及随后发布的源代码，SCAN FOR OBSCENITIES（和你不应该说的其他事情，例如，“我的老板让我做这个“，”这段代码很可怕“等等。此外，拼写检查评论可能会有所帮助，因为人们错误地拼写单词会损害您的可信度。
答案 1 :(得分：11)
请确保您的标头不会生成任何编译器警告。
答案 2 :(得分：3)
总是让某人（最好不止一个人）通过标题寻找任何看起来不专业的人。您可以先使用代码格式化程序和其他自动工具。
对于评论，让他们寻找任何不专业或暂时的东西。纠正错误拼写。确保它们准确无误。有一种标准的格式化方法，并坚持下去。
检查所有标识符名称。它们应符合风格指南并以专业命名。
确保所有必要的评论都在那里。这包括顶部的版权和联系信息。想出一个记录类等的标准方法，并加以实施。
基本上，从我的观点来看，你希望你的标题看起来像是无人驾驶者没有创造力或幽默感而产生的，但是他们是完全一致的（有点像CPA刻板印象）。 （这有点像要求开发人员在客户访问办公室时穿西装 - 如果他们看不到开发人员真正喜欢的东西，客户会更开心。）
答案 3 :(得分：2)
如果您拥有文档的编码标准/格式通常会更好，客户会在第一次创建代码时看到开发人员自己遵循的文档，因此您不会花时间在发布之前清理代码，例如现在。
此外，Visual Studio和其他几个IDE都有一个“自动格式化”选项，您可以在其中设置样式并将其应用于您的代码（制表符，空格等）。我认为这主要是你在这里要求的。
答案 4 :(得分：2)
我对这个主题不是很熟悉，但对于开源项目，你经常在标题的顶部有许可证和版权声明。这可以避免一些法律问题。
答案 5 :(得分：2)
根据我的经验，经常使用内部使用的标头并自动清理以供公众使用是一项艰巨的任务，而且肯定容易出错。最终，不一致的格式或不恰当的评论将不可避免地蔓延。
在许多情况下，最好将所有东西都包装成一个小而干净的界面，其标题始终保持干净并尽可能注释;例如，对该文件的修改应经过特别仔细的审查。
答案 6 :(得分：2)
与删除苛刻的评论同样重要的是添加必要的评论。您可能需要添加的内容：
答案 7 :(得分：1)
天儿真好，
在C ++中，我喜欢使用Handle-Body idiom尽可能地将实现与公共接口分离。
您还应该确保任何样板，例如版权声明是一致的和最新的，例如对于今天发布的代码，版权在2008年不会过期。
在命名约定，格式，布局和类设计的所有公共头文件中保持一致，否则会给客户留下不专业的印象。
确保头文件中没有“使用”声明。滥用“使用”dec会严重影响无意中的副作用。
如前所述，请确保您的标头不会生成任何警告。
最后。确保你有一些好的API文档来处理你的头文件。
不要像提供众所周知的邮政编码查询产品的公司。 C API的第一个版本附带了极少基于Windows GUI版本的最小文档。头文件只包含其参数只有类型而没有名称的函数。并且没有评论。
只有这样才能确定函数实际执行的操作是对提供的简单查找示例程序进行逆向工程并对其进行反向工程。
尽管如此，在完成这项工作之后，我每年还为BBC的儿童节省了数万英镑，因为筹款包的地址比前几年更有可能是正确的！