不要再争论代码风格了!

【伯乐在线导读】:很多程序员喜欢争论代码风格。别否认哦,类似的话题总能吵起来。Bill Sourour 认为:代码风格没有绝对的对错,只要团队代码风格统一就行了。Bill 觉得比较安全的做法:① 通过工具自动规范代码风格;② 参照名声好的大公司使用的代码风格。


  • 用制表符(Tab)还是空格(Space)?
  • 在同一行中使用大括号,还是新起一行?
  • 每行是 80 个字符,还是 120 个?

程序员都喜欢争论这类型的事情,制表符和空格的争论,甚至在 HBO 的《硅谷》中出现了。

对于这些争论,在这篇文章中,我最后会给出一个明确的答案。

在我的职业生涯早期,我也参与到了这些“圣战”中。我会阅读一些文章,来了解为什么这个规范是正确的,而另外一个完全是错的。然后趾高气扬地对其他与我争论的人说他们是错的,而我是正确的。

寻找正确的答案,这花费了我多年的时间,并且我也找到了,但最终的答案就是……

这些事情无关紧要!

一致性很重要、可读性很重要!争论并强调某一个规范比另外一个规范好,都是一些无关紧要的事。

在过去的 20 多年,我关注了各种语言规范。并遵循了不同语言的不同规范。但是,没有一个规范会减少我的 bug 数量,或者使我的代码效率更高。

随着时间的推移,不使我犯错、整洁、格式化的代码,更易于改动和维护,这就是好的代码。

想着如何把你的代码写的更漂亮,这并不是坏事,但执着于此,常常会把问题归根于此,并为自己的拖延找借口。

实际上,我们如此拖延主要是因为编码时遇到了难题。并且这个问题对当时的我们来说很难解决–尤其是当我们首次遇到这种级别的难题时,我们会被这种复杂的问题吓到,导致我们怀疑自己没有这个能力去解决它。

但如果是争论一些琐事,我们就会游刃有余、有安全感。因为在争论琐事的过程中我们的不自信 (perceived incompetence )就不太可能暴露出来。

争论一些琐碎的事情而逃避那些困难的问题是一种常见的现象,这里有大量著名的理论描述了这一现象。

有一个最著名的理论就是帕金森琐碎定律 (Parkinson’s Law of Triviality),它描述了:一个组织中的成员往往会把过多的经历,花费在一些琐碎的事情上。

帕金森用了一个虚构例子来解释了这个定律:在一个审核新核电站计划的委员会中,会员把主要的时间用于争论员工自行车棚使用什么材料,忽略了被提议的核电站计划本身,而这个恰恰是最重要、最复杂的问题。

由于在这个经典的例子中使用了自行车棚来阐述问题,丹麦的开发者 Poul-Henning Kamp 创造了新的术语来描述这种现象,叫“自行车棚效应(bike shed effect)”,或者简单地叫“自行车棚(bike shedding)”。

如果你从事软件开发,特别是你在社交媒体上与其他程序员闲聊时,你可能每天都会遇到类似“自行车棚”案例(bike-shedding)

如果你发现自己正在线上或者线下中和程序员同事进行热烈的争论时,你应该记住 Sayre 定律:

“在任何争论中,主观上的重要程度,往往和问题的实际重要程度成反比。

作为一个顾问/咨询师,我在不同的客户之间奔波,他们都有自己的规则和习惯。因此,在很久之前我就坚定认为,成功的唯一方式就是,放弃琐碎的事情,专注有挑战的问题。把它应用到编码规范上,我就可以收获到我想要的东西,并且不会变得浮躁。

如果你正在寻找一种属于自己的代码风格,我建议你先问自己两个问题:

  1. 是否有现成的工具,只需简单操作,就可以自动按照你的代码风格规则,来格式化代码?
  2. 这个工具以及它支持的代码风格规则是否有人在持续维护,或者是否有一些知名公司在用? 

对于上面的两个问题,如果你的答案都是“是的”,那么你就可以放心用这个代码风格。就是这么简单。

下面有一些代码格式化工具:

2 2 收藏 2 评论

关于作者:周进林

茫茫大海中的一枚程序猿,为了进化为一个高富帅人类而努力着。关注java、python、linux、vim等(新浪微博:@酒肉和尚--进林) 个人主页 · 我的文章 · 19 ·  

相关文章

可能感兴趣的话题



直接登录
最新评论
跳到底部
返回顶部