引语：这两天看到有人推荐这个项目，觉得挺有意思，就随手翻译了下，原文自然也是很易懂的，不喜欢翻译风格的自然可以移步原文。看了几遍之后，笑着笑着就哭了，发现自己有几条还是中了的。希望大家也是有则改之，无则加勉，不要成为自己讨厌的那种人！
原则如下
💩 命名变量，如果你觉得疑惑的时候那就对了！
键盘敲越少，时间跑不了。
Good 👍🏻
let a = 42;
Bad 👎🏻
let age = 42;
💩 混合式命名变量/方法
庆祝差异吧。
Good 👍🏻
let wWidth = 640;
let w_height = 480;
Bad 👎🏻
let windowWidth = 640;
let windowHeight = 480;
💩 绝不写注释
反正也没人读你的代码。
Good 👍🏻
const cdr = 700;
Bad 👎🏻
通常注释需要包含一些 “why” 而非一些 “what”，如果代码并不能清晰地表明 “what” ，那这代码就太乱了。
// The number of 700ms has been calculated empirically based on UX A/B test results.
// @see: <link to experiment or to related JIRA task or to something that explains number 700 in details>
const callbackDebounceRate = 700;
💩 一律使用母语注释
如您违反了“无注释”原则，则至少尝试使用与编写代码所使用的语言不同的语言编写注释。 如果您的母语是英语，则可能违反此原则。
Good 👍🏻
// Закриваємо модальне віконечко при виникненні помилки.
toggleModal(false);
Bad 👎🏻
// Hide modal window on error.
toggleModal(false);
译者注：这一点的话大部分是针对开源项目，公司内部项目用母语也没啥毛病。
💩 尽可能地去尝试不同的格式
庆祝差异吧。
Good 👍🏻
let i = ['tomato', 'onion', 'mushrooms'];
let d = [ "ketchup", "mayonnaise" ];
Bad 👎🏻
let ingredients = ['tomato', 'onion', 'mushrooms'];
let dressings = ['ketchup', 'mayonnaise'];
💩 尽可能养成代码一行流
Good 👍🏻
document.location.search.replace(/(^\?)/,'').split('&').reduce(function(o,n){n=n.split('=');o[n[0]]=n[1];return o},{})
Bad 👎🏻
document.location.search
.replace(/(^\?)/, '')
.split('&')
.reduce((searchParams, keyValuePair) => {
keyValuePair = keyValuePair.split('=');
searchParams[keyValuePair[0]] = keyValuePair[1];
return searchParams;
},
{}
)
💩 默默承受“失败”
无论何时捕获了异常，并不必让他人知晓。别打日志，别抛出错误模型，徒留一片清冷。
Good 👍🏻
try {
// Something unpredictable.
} catch (error) {
// tss... 🤫
}
Bad 👎🏻
try {
// Something unpredictable.
} catch (error) {
setErrorMessage(error.message);
// and/or
logError(error);
}
💩 广泛地使用全局变量
全球化原则。
Good 👍🏻
let x = 5;
function square() {
x = x ** 2;
}
square(); // Now x is 25.
Bad 👎🏻
let x = 5;
function square(num) {
return num ** 2;
}
x = square(x); // Now x is 25.
💩 创建一些你并不会用到的变量
以防万一嘛。
Good 👍🏻
function sum(a, b, c) {
const timeout = 1300;
const result = a + b;
return a + b;
}
Bad 👎🏻
function sum(a, b) {
return a + b;
}
💩 如果语言允许，请不要指定类型 和/或 不进行类型检查
Good 👍🏻
function sum(a, b) {
return a + b;
}
// Having untyped fun here.
const guessWhat = sum([], {}); // -> "[object Object]"
const guessWhatAgain = sum({}, []); // -> 0
Bad 👎🏻
function sum(a: number, b: number): ?number {
// Covering the case when we don't do transpilation and/or Flow type checks in JS.
if (typeof a !== 'number' && typeof b !== 'number') {
return undefined;
}
return a + b;
}
// This one should fail during the transpilation/compilation.
const guessWhat = sum([], {}); // -> undefined
💩 你需要一段永远都不会执行的代码
这是你的 “Plan B”。
Good 👍🏻
function square(num) {
if (typeof num === 'undefined') {
return undefined;
}
else {
return num ** 2;
}
return null; // This is my "Plan B".
}
Bad 👎🏻
function square(num) {
if (typeof num === 'undefined') {
return undefined;
}
return num ** 2;
}
💩 三角形原则
像小鸟一样——筑巢，筑巢，筑巢。
Good 👍🏻
function someFunction() {
if (condition1) {
if (condition2) {
asyncFunction(params, (result) => {
if (result) {
for (;;) {
if (condition3) {
}
}
}
})
}
}
}
Bad 👎🏻
async function someFunction() {
if (!condition1 || !condition2) {
return;
}
const result = await asyncFunction(params);
if (!result) {
return;
}
for (;;) {
if (condition3) {
}
}
}
💩 缩进混乱
避免缩进，因为缩进会使复杂的代码在编辑器中占用更多空间。如果你无法避免得有缩进，那就把它们弄乱。
Good 👍🏻
const fruits = ['apple',
'orange', 'grape', 'pineapple'];
const toppings = ['syrup', 'cream',
'jam',
'chocolate'];
const desserts = [];
fruits.forEach(fruit => {
toppings.forEach(topping => {
desserts.push([
fruit,topping]);
});})
Bad 👎🏻
const fruits = ['apple', 'orange', 'grape', 'pineapple'];
const toppings = ['syrup', 'cream', 'jam', 'chocolate'];
const desserts = [];
fruits.forEach(fruit => {
toppings.forEach(topping => {
desserts.push([fruit, topping]);
});
})
💩 不要锁定你的依赖项（即不要指定版本）
以不受控制的方式更新对每个新安装的依赖关系。为什么要坚持旧版呢，让我们使用最先进版本的库。
Good 👍🏻
$ ls -la
package.json
Bad 👎🏻
$ ls -la
package.json
package-lock.json
💩 长方法总比旧的好
不要拆分你的代码逻辑以致于清晰可读。万一 IDE 的搜索功能不能用了且无法找到所需的文件或方法怎么办？
- 一个文件 10000 行代码是 OK 滴！
- 一个方法主体 1000 行代码是 OK 滴！
- 在一个
service.js文件中处理许多服务（第三方以及内部的，还有一些帮助程序，数据库手写的ORM和jQuery滑块）？也是 OK 滴！
💩 测试？测它干嘛？
这是重复且不必要的工作。
💩 尽可能强硬地拒绝各种代码 linter
你想怎么写就怎么写，特别是团队中不只一个开发者的时候。这是一条 “自由” 原则。
💩 开始你的项目时，不要有 README 文件
并这么保持下去。
💩 你需要有一些没必要的代码
不要删除那些你的 App 用不到的代码。最多，注释掉嘛！
