04自动执行编码标准
You've probably been there too. At the beginning of a project, everybody has lots of good intentions — call them "new project's resolutions." Quite often, many of these resolutions are written down in documents. The ones about code end up in the project's coding standard. During the kick-off meeting, the lead developer goes through the document and, in the best case, everybody agrees that they will try to follow them. Once the project gets underway, though, these good intentions are abandoned, one at a time. When the project is finally delivered the code looks like a mess, and nobody seems to know how it came to be this way.
你可能也遇到过这种情况。在一个项目开始的时候，每个人都有很多好的建议 --- 姑且称之为“新项目的决议”。很多时候，这些决议都写在文档中上。而关于代码的决议，最终会体现在项目的编码标准中。在启动会议期间，主要开发人员将审阅文档，（在最好的情况下）每个人都保证他们将尝试遵循这些规范。然而，一旦项目开始，这些规范就被抛弃了。这种情况重复了一次又一次。当项目最终交付时，代码看起来一团糟，而且似乎没人知道它是如何变成这样的。
When did things go wrong? Probably already at the kick-off meeting. Some of the project members didn't pay attention. Others didn't understand the point. Worse, some disagreed and were already planning their coding standard rebellion. Finally, some got the point and agreed but, when the pressure in the project got too high, they had to let something go. Well-formatted code doesn't earn you points with a customer that wants more functionality. Furthermore, following a coding standard can be quite a boring task if it isn't automated. Just try to indent a messy class by hand to find out for yourself.
问题是什么时候出现的呢？可能在开启动会议时已经出现了。一些项目成员压根没有注意。有些人甚至不明白做这些事情的意义。更糟糕的是，还有一些人不同意，他们已经在心里策划他们自己的编码标准了。最终，有些认真听的人同意推行这些规范，但当项目压力太大时，他们也不得不放手。毕竟有良好编码风格的代码并不能从想要更多功能的客户那里获取任何好感。此外，如果不采用自动化的方式推行，遵循编码标准会是一项相当乏味的任务。如果你不信，那就试着纯手工调整一下一个排版很糟的类文件。
But if it's such a problem, why is that we want to have a coding standard in the first place? One reason to format the code in a uniform way is so that nobody can "own" a piece of code just by formatting it in his or her private way. We may want to prevent developers using certain anti-patterns, in order to avoid some common bugs. In all, a coding standard should make it easier to work in the project, and maintain development speed from the beginning to the end. It follows then that everybody should agree on the coding standard too — it does not help if one developer uses three spaces to indent code, and another one four.
但在这种情况下，为什么我们还是要有一个编码标准呢？以统一的编码标准格式化代码的一个原因是，没有人能够仅仅通过他或她的私人方式排版来“拥有”一段代码。我们可能希望防止开发人员使用某些反模式，以避免一些常见的错误。总之，一个编码标准应该使项目中的工作变得更容易，并始终保证项目开发速度。项目中的每个人都应该遵从相同的编码标准---如果一个开发人员使用三个空格缩进代码，而另一个人使用四个空格缩进代码，最终代码还是会一团糟。
There exists a wealth of tools that can be used to produce code quality reports and to document and maintain the coding standard, but that isn't the whole solution. It should be automated and enforced where possible. Here are a few examples:
Make sure code formatting is part of the build process, so that everybody runs it automatically every time they compile the code.
Use static code analysis tools to scan the code for unwanted anti-patterns. If any are found, break the build.
Learn to configure those tools so that you can scan for your own, project-specific anti-patterns.
Do not only measure test coverage, but automatically check the results too. Again, break the build if test coverage is too low.
有很多工具可以用来生成代码质量报告，记录和维护编码标准，但这些工具并不是完整的解决方案。应尽可能实现自动化并强制执行。以下是几个例子:
确保代码格式化是构建过程的一部分，以便每个人每次编译代码时都会自动运行它。
使用静态代码分析工具扫描代码中不需要的反模式。如果发现任何问题，则中断构建。
学会配置这些工具，以便您可以扫描自己的特定项目的反模式。
不仅要计算单元测试覆盖率，而且还要自动检查结果。如果单元测试覆盖率太低，则中断构建。
Try to do this for everything that you consider important. You won't be able to automate everything you really care about. As for the things that you can't automatically flag or fix, consider them to be a set of guidelines supplementary to the coding standard that is automated, but accept that you and your colleagues may not follow them as diligently.
将你认为重要的事情都尽量向这个方向调整。你无法将你关心的所有问题都进行自动化。对于不能自动标记或修复的内容，则把它们当作对自动化编码标准的一套补充，但同时要意识到，你和你的同事可能并不会那么努力地遵循它们。
Finally, the coding standard should be dynamic rather than static. As the project evolves, the needs of the project change, and what may have seemed smart in the beginning, isn't necessarily smart a few months later.
最后，编码标准应该是动态的而不是静态的。随着项目的进展，项目的需求会发生变化；那些在项目初期十分有用的规则，在几个月后可能就没实际意义了。
Last updated