不要再争论代码风格了！很多程序员喜欢争论代码风格。别否认

《不要再争论代码风格了！》的文章是傻大方资讯网小编转载于网络，如有侵权请联系删除。

（点击

上方公众号

，可快速关注）

英文：Ben Sourour，编译：伯乐在线/周进林

【伯乐在线/程序员的那些事导读】：很多程序员喜欢争论代码风格。别否认哦，类似的话题总能吵起来。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 定律：

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

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

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

是否有现成的工具，只需简单操作，就可以自动按照你的代码风格规则，来格式化代码？

这个工具以及它支持的代码风格规则是否有人在持续维护，或者是否有一些知名公司在用？

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

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

DotNet Code Formatter

Java: Google-Java-Format

Javascript Standard Style （注意，这只是一个产品名，不是 JS 官方标准）

PHP Coding Standards Fixer

Python: Google’s YAPF

Ruby: Rubocop

微信不支持外链，点击「阅读原文」查看上述工具

看完本文有收获？请转发分享给更多人

关注「程序员的那些事」，提升编程技能