不要再争论代码风格了！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

程序喵