以同理心进行开发：使用代码风格指南

由 Mux 赞助的 DEV 全球展示挑战赛：展示你的项目！

成为一名开发者并不意味着你只会不停地写代码。你不仅要写代码，还要沟通交流，与他人的代码互动，甚至可能还要参加视频会议。无论你做什么，保持步调一致总是有益的。

在我各种开发经验中，我发现，设定“好的代码”或“干净的代码”的标准，对于帮助那些不一定知道该问什么问题，甚至不知道自己是否有任何问题的人来说，是一个很好的方法。

什么是好的代码？

说实话，好的代码取决于你怎么定义它。只要它能运行/能编译/能做到什么程度，它就是代码。你可以向你的同事/伙伴展示好的代码是什么样子，但除非你把它写下来或者编纂成规范（笑），否则大家还是会为了完成工作而写出他们想写的东西。

为什么有必要这样做？

简单来说：这样大家才能说同一种语言。如果每个人都用类似的语言编写代码，那么代码审查、发现 bug 和结对编程都会更容易。我发现自己在与他人结对编程时，至少要先做两件事才能真正开始思考对方提出的问题：

1. 适应代码风格​​，无论是 CSS 规则的组织方式还是 JS 的抽象程度。
2. 在理解内容并提出建议之前，我会重新通读所有内容。

我觉得如果大家都以类似的方式做事，事情进展会更快。

风格指南有助于实现以下目标：

• 确保每个人都在编写类似的代码
• 确保可读性
• 让新开发人员逐步熟悉“好代码”或“整洁代码”的“标准”。
• 澄清了上述原本含糊不清的术语可能引起的任何问题。

一份好的风格指南应该是什么样的？

嗯，这完全取决于你！不过我有一些建议：

CSS

• Airbnb 的 CSS 样式指南
• Harry Roberts 的 CSS 指南
• Andy Bell 的 CUBE CSS

Javascript

• Airbnb 的 Javascript 风格指南
• Google 的 Javascript 风格指南
• StandardJS（强制执行的风格指南）

还有很多其他选择，其中一些还带有自己的工具，例如 Airbnb 的工具banel-preset-airbnb，甚至是 StandardJS 的工具npm install standard。

与团队就“优质代码”达成共识，不仅可以改善沟通和团队协作，还能减少你在使用 git blame 之前可能会有的“天哪，这是谁写的？”的反应 :)