不要再争论代码风格了!

很多程序员喜欢争论代码风格。别否认哦,类似的话题总能吵起来。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. 这个工具以及它支持的代码风格规则是否有人在持续维护,或者是否有一些知名公司在用? 

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

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

  • DotNet Code Formatter

  • Java: Google-Java-Format

  • Javascript Standard Style (注意,这只是一个产品名,不是 JS 官方标准)

  • PHP Coding Standards Fixer

  • Python: Google’s YAPF

  • Ruby: Rubocop


未经允许请勿转载:程序喵 » 不要再争论代码风格了!

点  赞 (0) 打  赏
分享到: