4. 自动化你的编码标准

自动化你的编码标准

        你可能已经这样做了。在一个项目开始时，每个人都有很多好的意向——称之为“新项目决心”。经常是，这些决心很多已经书面记录下来了，和编码相关的最终就是项目的编码标准。在项目启动会议上，主开发过一遍这个文档，而且最好的情形是，每个人都同意会遵守它们。然而一旦项目开始后，这些好的意向就一个一个被抛弃了。等项目交付时，代码已经看起来是一团糟，而且似乎没有人知道它是怎么变成这个样子的。
        是什么时候出了问题呢？可能在项目启动会上就有了。某些项目成员没注意，其他一些没有理解。更坏的可能是，有些人根本就不同意而且已经在计划对编码标准的反叛了。最终，有些人理解了也同同意了，但项目的压力变得太大了时，他们只好放任自流了。格式良好的代码相对于一个需要更多功能的客户，不会让你投入更多。此外，如果不自动化的话，遵循编码规范可能是一项很枯燥的任务，只要自己尝试一下手动地调整一个混乱的类的缩进就会明白。
        既然有这个问题，但是为什么我们还是在一开始要有一个编码标准呢？一个原因是用统一的方法格式化代码，就没有人可以通过用个人的方法格式化来“独占”一块代码。我们可能要防止开发人员使用某些“反模式”，以避免一些常见的缺陷。总的来讲，一个编码标准应该很容易在项目中使用，也可以自始至终保证开发速度。因此，每个人都应该同意遵守编码标准——如果一个开发人员用三个空格缩进而另一个用四个，这是不行的。
        有很多用来生成代码质量报告以及记录和维护编码标准的工具，但那不是完整的解决方案。如果可能的话，应该自动化和强制花。以下是一些例子：
        · 确保格式化代码是构建过程的一部分，这样每个人在每次编译代码时都可以自动运行。
        · 使用静态分析工具扫描代码，找出其中的反模式；如果有的话，中断构建。
        · 学习配置这些工具，这样可以为自己扫描特定项目相关的反模式。
        · 不要只度量覆盖测试率，还要自动检查结果；同样，如果覆盖率太低就中断构建。
        对你认为重要的每一件事都这么做。不是所有你在意的事情都可以自动化，对于不能自动标记或修复的，将其作为以自动化了的编码标准的辅助性指导，但你或者你同事没严格遵守也是可以接受的。
        最后，编码标准应该是变化的，而不是静止的。随着项目的进展，项目需求会变化，一开始很精巧的东西，几个月之后可能就不是那么必需的了。 

原文：Automate Your Coding Standard byFilip van Laenen