你可能也感同身受。在项目刚开始时，每个人都对项目有很多提议——叫做“新项目决议”。经常，这些决议会被写进文档。让代码符合项目的代码标准。在项目启动会议时，开发主管会通过这些文档，在理想情况下，每个人都同意遵循这套规则。一旦项目开始，这些好的建议会被一个又一个地抛弃。到项目收尾时，这些代码将混乱不堪，而且居然没人知道是怎么成这样的。
什么时候开始出错的？可能在项目启动会议就开始了。一些项目成员没有注意到，其他人可能也不理解。但糟糕的是，一些反对声和已经纳入计划的代码标准有冲突。最终，一些人可能发现了问题所在，但项目压力太大的时候，又不得不让事情继续向前推。良好的代码格式化并不能让需要更多功能的用户为你点赞。而且，如果无法自动完成的代码格式化真的很让人反感。仅能自己手动去缩进那些混乱的class。
但如果这是个问题，为什么我们刚开始就要确定一套代码标准？原因之一是格式化成统一风格后没人可以用自己的风格去“占有”一段代码。我们想要阻止开发人员使用明某些反模式，为了避免一些常规性的bug。在所有情况下，一套代码标准应该在整个项目中更容易被执行，以便从头至尾维持开发速度。接着，每个人都应该同意这套风格——如果有人用三个空格缩进，有人却用四个，那这风格就完全没意义了。
有大量的工具可以用来生成代码质量报告以及文档，以维持代码标准，但这不是全部解决方案。它应该尽可能被自动和强制执行。比如以下：
- 确保代码格式化属于工程建立的一部分，这样每个人在编译自己的代码事会被自动格式化。
- 使用静态分析工具去扫描代码是否有反模式，一旦发现，中断构建。
- 学习配置这些工具以便你能扫描自己代码，特定项目的反模式。
- 不仅要测量测试覆盖率，还要自动检查这些结果。再有，如果测试覆盖率太低也要中断构建。
尝试去把你认为重要的任何事做到这一点。你不能让每件你关心事都自动化。对于这些无法自动标记或修复的事情，考虑为它们制定一套补充指南，以确保代码标准能被自动化，但你和你的同事们未必会遵循它。
最后，代码标准应该是动态的而非静态的，随着项目的发展，它需要随项目改变，因为刚开始看起来英明的事情，过几个月可能就没那么英明了。
