摘要：但是，有条原则应该是对的少数服从多数用工具统一风格。我曾经以为，程序员有自己独特的代码风格挺好的。业界有一些流行的代码风格，比如和。你也可以使用来统一风格。比如，的配置，只能统一示例的代码风格，而不能统一后面两者。相比于代码风格，我更推荐。
译者按: 关于代码风格，不同的人有不同的偏好，其实并没有什么绝对的对错。但是，有 2 条原则应该是对的： 少数服从多数；用工具统一风格。
原文: Why robots should format our code for us
译者: Fundebug
为了保证可读性，本文采用意译而非直译。另外，本文版权归原作者所有，翻译仅用于学习。
我曾经以为，程序员有自己独特的代码风格挺好的。因为，一个成熟的程序员应该清楚，好的代码应该是怎样的。
我的大学教授告诉我，他的学生在用我的代码，因为我的代码风格不一样。我想了一下，也许是因为我的代码至少是有风格的，而其他人的代码一团糟。
一些示例 示例 1：读了The Programmers’ Stone之后，我把大括号这样写：
if (food === "pizza")
{
alert("Pizza ;-)");
}
else
{
alert("Not pizza ;-(");
}
但是，我意识到在前端社区里，也许只有我一个人这样写的。而其他人都是这样写的：
if (food === "pizza") {
alert("Pizza ;-)");
} else {
alert("Not pizza ;-(");
}
或者这样：
if (food === "pizza") {
alert("Pizza ;-)");
}
else {
alert("Not pizza ;-(");
}
于是，我改变了风格，采用了最后一种写法。
示例 2将多个方法链接起来时，我喜欢这样写：
function foo(items) {
return items
.filter(item => item.checked)
.map(item => item.value)
;
}
示例 3
读了Why you should enforce Dangling Commas for Multiline Statements，我意识到了trailing commas写法更加易于重构：
const food = [ "pizza", "burger", "pasta", ]
但是，这种写法非常少见。我审查过的代码中，没人这样写。于是，我只能放弃这种写法，向现实世界低头。
示例 4我还有一个不合群的习惯。在行尾写代码注释之前，我习惯敲 2 个空格：
const volume = 200; // ml
我觉得这样写好看些。但是，这会导致代码不一致，因为其他人只敲一个空格。
JavaScript 开发者是怎样做的很遗憾，JavaScript 没有官方的代码风格。业界有一些流行的代码风格，比如Airbnb和Standard。使用它们的话，团队成员之间的代码会更易读。
你也可以使用ESLint 来统一风格。但是它并不能保证代码 100%一致。比如，ESLint 的 Airbnb 配置，只能统一示例 1的代码风格，而不能统一后面两者。
JavaScript 开发者应该怎么做？有一些语言有非常严格的代码风格，并且有工具可以用于统一风格。因此，开发者不需要浪费时间去争论代码风格的优劣。例如，Reason 语言的Refmt，和 Rust 语言的Rustfmt。
现在，JavaScript 终于有了一个解决方案。有一个新工具，叫做Prettier，它运用自身的规则将你的的代码重新格式化。无论你之前的代码风格是怎样。
我们不妨试用一下 Prettier。
输入代码是这样的：
if (food === "pizza")
{
alert("Pizza ;-)");
}
else
{
alert("Not pizza ;-(");
}
function foo(items) {
return items
.filter(item => item.checked)
.map(item => item.value)
;
}
const food = [
"pizza",
"burger",
"pasta",
]
Prettier 处理之后的代码是这样的：
if (food === "pizza") {
alert("Pizza ;-)");
} else {
alert("Not pizza ;-(");
}
function foo(items) {
return items.filter(item => item.checked).map(item => item.value);
}
const food = ["pizza", "burger", "pasta"];
也许，你并不喜欢这种风格。比如，我不喜欢 else 放在大括号后面，也不喜欢把链式方法全部写在同一行。但是，我发现使用Prettier有很多益处：
几乎不需要做决定，因为 Prettier 的配置选项很少。
团队成员不需要为规则去争论。
开源代码开发者不需要去学习项目的代码风格。
不需要去修复 ESLint 报告的风格问题。
保存文件的时候可以自动统一风格。
结论Prettier 已经被一些非常流行的项目比如 React 和 Babel 采用了。对于我自己的项目，我已经开始从自己的个性化风格全部转为 Prettier 风格。相比于 Airbnb 代码风格，我更推荐 Prettier。
刚开始，我会觉得 Prettier 风格非常差。但是，当我发现自己需要手动去调整代码风格时，我意识到 Prettier 真的非常好用。
Prettier 可以在保存文件的时候可以自动统一风格：
感兴趣的话，可以按照这个教程配置 Prettier。
关于FundebugFundebug专注于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了10亿+错误事件，付费客户有Google、360、金山软件、百姓网等众多品牌企业。欢迎大家免费试用！
版权声明转载时请注明作者Fundebug以及本文地址：
https://blog.fundebug.com/2017/10/23/format-code-use-Prettier/
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/102775.html
摘要：由于本身不能个性化配置，有时可能会引起不适，但是至少保证团队成员可以轻易统一代码风格。就是将多于一个字母的合成一个字形。自从年双十一正式上线，累计处理了亿错误事件，得到了金山软件等众多知名用户的认可。 译者按： IDE是生产力的保证！ 原文：Visual Studio Code Settings and Extensions for Faster JavaScript Develop...
摘要：官网地址推荐指数颗星推荐理由自动化部署和集成部署的好工具，操作简单，显示友好，具备多种插件，应有尽有，支持多类型语言的项目集成和部署。官网地址如果你有其他好用的工具，不妨也分享一下原博客链接前端开发团队的工具链 汇集前端开发团队中经常使用的好工具，分享给大家！ 注：都是开源工具 showImg(https://segmentfault.com/img/remote/1460000019...
摘要：整个代码检查和格式化流程应该规范为如下步骤使用并且尝试自动修复所有问题有提示，可以进行修复，按照配置文件来进行修复。参考文档如何花分钟解决产生的各种错误的记忆现场本文转载自我的更新版梳理前端开发使用和来检查和格式化代码问题 更新版，之前的版本可以看这里：梳理前端开发使用eslint和prettier来检查和格式化代码问题 一、问题痛点 在团队的项目开发过程中，代码维护所占的时间比重...
摘要：但是关于代码风格，我们很难区分谁对谁错，不同的人有不同偏好，唯有强制要求才能规避争论。所以，团队关于代码风格必须遵循两个基本原则少数服从多数用工具统一风格。本文将介绍，如何使用来统一我们的前端代码风格。 加分号还是不加分号？tab还是空格？你还在为代码风格与同事争论得面红耳赤吗？ 正文之前，先看个段子放松一下： 去死吧！你这个异教徒！ 想起自己刚入行的时候，从svn上把代码checko...
摘要：忍无可忍只能拔枪相见了。而只关心格式化文件最大长度混合标签和空格引用样式等。可见，代码格式统一的问题，交给再合适不过了。和配合使用，风味更佳。我的配置文件如下到此，安装完毕，使用就可格式化代码。两者配合才能使项目代码优雅健壮 试想一个多人开发的项目，每次同步代码，看到各个风格迥异，换行空格混乱，4格，2格缩进交替上演的代码文件，分分钟逼死强迫症啊。忍无可忍只能拔枪相见了~~。统一的代码...
阅读 1701·2021-11-18 10:02
阅读 2217·2021-11-15 11:38
阅读 2664·2019-08-30 15:52
阅读 2189·2019-08-29 14:04
阅读 3230·2019-08-29 12:29
阅读 2085·2019-08-26 11:44
阅读 993·2019-08-26 10:28
阅读 829·2019-08-23 18:37
