在我眼中，干净的代码就是简单、易于理解的代码。不过分设计，模板文件尽可能地少，语义明确。那么，这样是否就意味着代码越少越干净呢？

我不这么认为。大多数情况下，更少的代码往往语义更模糊，更难理解（因此更难维护）。

当我使用jBehave工作和测试元过滤时，我写了类似于下面的代码：

在之后对这些代码的讨论中，我的一个同事表示，他刚刚删除了一些“没有必要”的私有方法，于是代码变成了这样：

显然，方法更短，代码更少了。对我们来说，使用这样的类，或许能让我们在工作时对这个方法所发生的变化一目了然。但是如果有新加入项目的人呢，并且这家伙之前从未使用过jBehave呢？对他而言，长一点的代码反而可以获取更多的信息，即使他不知道jBehave是如何工作的，不清楚“元过滤器”是什么，不懂minus的意思——但是至少能理解我们想要实现的目标。

当我试图解释自己的看法时，其他开发人员虽然同意我的观点，但却认为通过添加注释也可以达到相同的效果。是的，我完全同意，添加注释肯定是有效的。这只是风格问题。我个人不喜欢注释而已，不过，在上述这种情况下，或许注释的确是更好的选择，因为我们可以通过注释解释元过滤器代码和jBehave层文件之间的联系。

所以最后，代码成了这样的：

当然你可以说，这样一个小小的事例不值一提。但是，一个项目的风格，我认为是非常重要的。你也可以通过讨论具体的例子找到一种普遍的风格。也许其他开发人员会因此而考虑他的代码是否会给新加入的同事带来困惑，从而去添加注释，而不是将方法缩成减一行代码。

结论

干净的代码并不总意味着更少的代码。所以，你需要在编写更多的小方法和缩减代码行数之间权衡得失。关于编码风格，以后我会再发帖子予以讨论。