编程的97件事——4、自动化你的编码标准

^{自动化你的编码标准}

你很可能也经历过这个。在项目开始的时候，每个人都有很多好的想法——姑且称之为“新项目决心”。这些决心经常会以文档的形式记录下来。是关于项目的编码规范的。在开工会议上，研发主管会和其他开发人员一起过一下这个文档，在最好的情况下，每个人都赞同按照编码规范工作。然而一旦项目开始进行，这些好的想法就一个一个的被抛弃了。等项目最终交付的时候，代码看起来一团糟，似乎没有人知道事情是怎么走到这一步的。

 

问题是什么时候开始出现的？也许在开工会议的时候就已经出现了。有些项目成员的注意力不在会议上，其他人并没有理解会议的目的。更糟的是，有人并不赞同这套规范，并且已经在心里计划自己的编码革命了。终于有人理解并同意这种编码规范了，但是当项目压力太大时，他们也不得不放弃了一些。比起更多的功能，规范的编码并不能让你从客户那里得分。而且，遵守一个没有自动化的代码规范，是一项非常无聊的任务。比如手动处理一个混乱的类的缩进，自己试试就知道了。

 

既然有这些问题，我们为什么一开始想要有代码规范呢？规定代码使用统一的格式规范的原因之一就是，这样可以避免某人通过自己私有的编码规范“占有”代码。我们或许想避免开发者使用某种“反模式”，以避免一些常见的bug。总之，编码规范使我们在项目中工作更容易，并且能在整个项目过程中维持开发速度。要达到这些效果需要每个人都遵守它——如果有人用3个空格缩进，有人用4个，就没有意义了。

 

现在有许多工具可以用来生成代码质量报表和维持编码规范并记录文档，但这不能解决全部问题。应该自动化并尽可能的强制执行。下面是一些示例：

• 确保代码格式是构建过程的一部分，这样每个人编译代码的时候都会自动进行格式检测。
• 使用静态代码分析工具扫描反模式的部分。一旦找到，停止构建。
• 学会配置这些工具，这样就可以为自己的项目定制扫描反模式的策略。
• 不仅度量测试覆盖率，还要将度量结果自动化。当测试覆盖率过低时，中断代码构建。

尽可能自动化所有你认为重要的事。你不可能自动化所有你在意的事情。对于那些还不能自动标记和解决的，把它们当做已经自动化的代码规范的补充。但是要接受你和你的同事可能不会像自动化的规范那样严格遵守。

 

最终，编码标准要是动态而不是静态的。随着项目的进展，项目的需求会变，一开始似乎是聪明的做法，几个月后也许就不聪明了。

 

原文地址：http://programmer.97things.oreilly.com/wiki/index.php/Automate_Your_Coding_Standard

为方便阅读，从本篇开始，会先放中文版本，后面是英文原文

---

Automate Your Coding Standard

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.

1Try 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.

By Filip van Laenen