本文翻译自"The Boy Scout Rule"，来自于《程序员应该知道的97件事》一书中的某个章节。

童子军有一条规则：“永远保持离开时的露营地比你发现它时更整洁”。如果你在地面上发现了脏东西，那么无论是否是你留下的，你都要将它清理干净。你有意地为下一组露营者改善环境。（实际上，由童子军之父罗伯特·斯蒂芬森·史密斯·贝登堡编写的原版规则是这样的：“尝试让这个世界在你离开时比你发现它时变得更美好。”）

如果我们在代码中遵循的这样一条类似的规则：“总是保持提交时的代码比Check Out时更整洁”？无论谁是代码的原作者，如果我们总是努力去改进模块，无论模块有多么小？结果会是怎样的呢？

我想如果我们大家都遵循这一简单的规则，我们将看到那些残酷地软件系统恶化腐朽的终结。相反，我们的系统将逐渐变得越来越好。我们也将看到整个团队将系统作为一个整体来完善，而不是每个人仅仅关心属于他们自己的那小部分。

我不认为这条规则的要求有过分之处。在你提交（check in）代码之前，你不必使每个模块都变得很完美。你只需使这些模块比check out它们时有一些改善即可。当然，这就意味着你添加到模块中的新代码必须是整洁的。同时它还意味着在你将代码提交回代码库之前，你至少整理了另外一处代码。你可能只是简单的改善了变量的命名，或者将一个冗长的函数拆分成两个短小简洁的函数。你可能打破了一个循环依赖，或者是增加一个接口以解除策略和细节之间的耦合。

坦率地说，这对我来说就像是一个再常见不过行为了-就像是便后洗手，或者将垃圾放入垃圾桶而不是随意丢到地板上一样。事实上，在代码中留下混乱应该与乱丢垃圾一样是不被接受的。它应该是一些不合乎规矩的行为。

不过，不仅仅是这些。照顾好自己的代码是一回事。照顾好团队的代码则是另外一回事。团队成员间相互帮助并且相互整理代码。他们遵循童子军规则，因为这不仅仅对自己有益，它对团队中的每个人都有益。

By Uncle Bob

代码风格（style）一直是一个见仁见智的问题，但是对于一个团队而言，如果能在代码风格上达成一致，显然无论对团队还是对个人来讲都是大有裨益的。

在这方面我们也曾做过努力，包括在团队中引入astyle工具，并在astyle的代码美化风格配置上，团队成员也集体达成过一致。但是在开发过程中还是出现了一些问题。最主要的就是对astyle工具使用不足：一些同事总是记得不停地写代码，但却忘记了按约定好的风格要求写代码或按照要求通过工具执行代码美化。

为了尽可能地保证提交到代码库中的代码都是风格良好的（也可以在代码评审时间接减少评审者提出有关代码风格问题而耗费的工作量），我们将代码风格检查加入到代码构建的关键流程中去，这样可以起到一个提醒大家注意代码风格的作用。与Java等语言相比，C语言的代码风格检查工具相对较少且工具的功能也很有限。我Google了半天才找到一款简单且实用的工具-c_style_check.py。这个检查脚本使用正则式匹配的方法按照你制定的规则对源码文件进行校验，如果发现不符合规则的代码行，则给出提示。另外考虑到我们内部的要求，我对这个脚本也作了一些改造，增加了一些校验规则，并把最新的脚本放到了这里。

目前的脚本较为简单，无法检查你的所有风格要求，不过它还是能检查出一些我们想要的不符合风格的地方。比如：不允许使用TAB字符、每行最大长度限制、在常见操作符(比如+,-,*,/,>,<等)两侧要添加空格、在){之间要求添加一个空格以及要求采用C传统注释方式等等。

另外，Google提供了一个强大的按照Google C++风格进行检查的代码检查器 – cpplint.py。不过尚没有C代码风格检查工具推出，不过cpplint.py这种级别的检查器是我们努力的方向。后续也许会逐步改进c_style_check.py。