在我眼中,干净的代码就是简单、易于理解的代码。不过分设计,模板文件尽可能地少,语义明确
在我眼中,干净的代码就是简单、易于理解的代码。不过分设计,模板文件尽可能地少,语义明确。
那么,这样是否就意味着代码越少越干净呢?
我不这么认为。大多数情况下,更少的代码往往语义更模糊,更难理解(因此更难维护)。
当我使用jBehave工作和测试元过滤时,我写了类似于下面的代码:
public Embedder configuredEmbedder() {
Embedder embedder = super.configuredEmbedder();
ignoreStoriesAndScenariosWithMetaInformationParameter(embedder, "ignore");
return embedder;
}
private void ignoreStoriesAndScenariosWithMetaInformationParameter(Embedder embedder, String ignoreParameter) {
embedder.useMetaFilters(Arrays.asList("-" + ignoreParameter));
}
在之后对这些代码的讨论中,我的一个同事表示,他刚刚删除了一些“没有必要”的私有方法,于是代码变成了这样:
@Override
public Embedder configuredEmbedder() {
Embedder embedder = super.configuredEmbedder();
embedder.useMetaFilters(Arrays.asList("-ignore"));
return embedder;
}
显然,方法更短,代码更少了。对我们来说,使用这样的类,或许能让我们在工作时对这个方法所发生的变化一目了然。但是如果有新加入项目的人呢,并且这家伙之前从未使用过jBehave呢?对他而言,长一点的代码反而可以获取更多的信息,即使他不知道jBehave是如何工作的,不清楚“元过滤器”是什么,不懂minus的意思――但是至少能理解我们想要实现的目标。
当我试图解释自己的看法时,其他开发人员虽然同意我的观点,但却认为通过添加注释也可以达到相同的效果。是的,我完全同意,添加注释肯定是有效的。这只是风格问题。我个人不喜欢注释而已,不过,在上述这种情况下,或许注释的确是更好的选择,因为我们可以通过注释解释元过滤器代码和jBehave层文件之间的联系。
所以最后,代码成了这样的:
@Override
public Embedder configuredEmbedder() {
Embedder embedder = super.configuredEmbedder();
// ignore stories and scenarios with meta information parameter @ignore.
embedder.useMetaFilters(Arrays.asList("-ignore"));
return embedder;
}
当然你可以说,这样一个小小的事例不值一提。但是,一个项目的风格,我认为是非常重要的。你也可以通过讨论具体的例子找到一种普遍的风格。也许其他开发人员会因此而考虑他的代码是否会给新加入的同事带来困惑,从而去添加注释,而不是将方法缩成减一行代码。
结论
干净的代码并不总意味着更少的代码。所以,你需要在编写更多的小方法和缩减代码行数之间权衡得失。
声明:本文内容来源自网络,文字、图片等素材版权属于原作者,平台转载素材出于传递更多信息,文章内容仅供参考与学习,切勿作为商业目的使用。如果侵害了您的合法权益,请您及时与我们联系,我们会在第一时间进行处理!我们尊重版权,也致力于保护版权,站搜网感谢您的分享!