为什么更漂亮
添加了对 GitHub PR liquid 标签的支持 #1784
在上一份工作中，我是一家小型创业公司的首席前端开发人员，也是唯一的前端开发人员。因此，我基本上可以随心所欲。我在 Twitter 上听说了 Prettier，决定试一试。我立刻就爱上了它，并把它添加为pre-commit hook。我不再在意代码的格式。我只需输入代码，点击保存，Prettier 就会神奇地让它看起来足够美观。
最终我离开了那份工作，去一家更大的公司尝试加入一个更大的团队。我被聘为高级前端开发人员——团队里已经有另外两个人了。我立即向同事们建议采用Prettier主题，却遭到了强烈的反对。他们的抱怨如下：
- 我就是不喜欢它的样子。
- 它占用了太多垂直空间。
我不同意这两项抱怨，但为了做一个好同事，我最终减轻了压力；只是在私下评论中提及此事（“是的，我真的很喜欢TypeScript Hero帮我处理导入和排序。这也是我喜欢 Prettier 的一点——它自动完成了很多我不需要手动做的事情”）。
随着我对代码库越来越熟悉，我开始为 JIRA 看板上的任务创建越来越多的拉取请求（别让我再说这个了）。我有点紧张，不知道我的代码会得到怎样的评价——毕竟，我职业生涯的大部分时间都是独自一人做前端开发。看到最初的几个拉取请求都充满了评论和“需要改进”的标记，我感到非常沮丧。这让我感觉很糟糕。难道我不是个好程序员吗？
95% 的评论都与格式问题有关。 “我们在这里多加了一行。”“我们更喜欢在这里加个逗号。”“我们是这样做的。”我最初提交的几个 pull request，也就是我最需要验证的时候，却因为我们没有使用 Prettier 而被批得体无完肤。
正如丹·阿布拉莫夫在推特上所说，
我们需要一些事情来让我们着迷。我们学习机械的规则，并乐于遵守它们。这比修复漏洞容易多了！我们把这些规则强加给新团队成员——“这是我们做事的方式，你这里漏了个空格和分号。”
这简直太疯狂了。打破这个恶性循环。使用Prettier。
我逐渐熟悉了他们的编码风格，相关的代码风格注释也减少了。现在，在我入职五个月后，团队终于同意使用 Prettier。这事儿就这么发生了。这周我认真地提了一下，我觉得在和同事们一起工作了一段时间后，他们更容易接受这个方案。前端团队负责人决定做些调查，最终也愿意尝试一下。
我们花了一整天的时间争论 Prettier 的设置（一开始他们想要 180 个字符的列！），但最终还是达成了一致。我们各自的编辑器里都安装了 Prettier，代码.prettierrc仓库里也都有。我感觉这应该是我们最后一次争论代码风格了。