UI树欲静有人说好的代码像一首诗，优雅而有内涵。
在日常开发中，维护别人老代码的时候是不是总感觉逻辑混乱，无法入手，就跟屎山一样？改一个 BUG 就如同在这座屎山上面艰难地再拉一坨……今天，我们从日常开发的角度上面谈谈如何让自己的代码更清晰，更易于维护，让别人看起来更有逼格。
变量命名
要写出好代码，变量命名至关重要。我们尽量采用富有表现力的词，英文不好多用翻译软件，保证不出现错误单词。编辑器可以安装相关的拼写检查、翻译插件。
- 不要缩写/简写单词，除非这些单词已经公认可以被这样缩写/简写。这样做导致可读性下降，意义表达不明确。反例：
Association ass、StringBuilder sb - 普通变量命名则使用名词及名词短语。比如
value、options、fileText、columnName等 - boolean 命名，如果表示“是不是”用
is...，表示“有没有”用has...，表示“能不能”用can...，表示“能不能怎么样”用...able - function 命名采用动词/宾语顺序。比如
getUserInfo、insertRows、clearValue等 - 避免使用
_开头、temp、my之类命名临时变量，临时变量也是有意义的，这些都会增加阅读代码时的噪点 - 避免无意义的命名，你起的每一个名字都要能表明意思。比如
userInfo、clickCount反例info、count
代码结构
好的代码结构有助于我们保持理性的思路，降低心智负担。
使用 const 定义
如果没有复杂的逻辑，用 const 就足够了，这样不用担心变量被重新赋值而引起意外情况。当这种模式写多之后，你会发现在项目中几乎找不到几个用 let 的地方。
// Bad
let result = false;
if (userInfo.age > 30) {
result = true;
}
// Good
const result = userInfo.age > 30;逻辑归类
在复杂的逻辑中，相关的逻辑尽量放在一起，并插入空行分开。使代码结构看起来清晰明了。
提前返回
在 function 中经常会遇到变量值为 undefined 的情况，这个时候则需要提前判断并阻止执行，避免一些不必要的分支（无 else），让代码更精炼。
if (!userInfo) {
return;
}
if (!hasMoney) {
return;
}
// 执行业务逻辑优雅的条件判断
简单的判断 if + return 就提前返回了。复杂逻辑 if else if 面条式代码不够优雅，想用 switch case？实际情况看来 if else 和 switch case 用法区别不大。
// if else
if (status == 1) {
console.log('processing');
} else if (status == 2) {
console.log('fail');
} else if (status == 3) {
console.log('success');
} else if (status == 4) {
console.log('cancel');
} else {
console.log('other');
}
// switch case
switch (status) {
case 1:
console.log('processing');
break;
case 2:
console.log('fail');
break;
case 3:
console.log('success');
break;
case 4:
console.log('cancel');
break;
default:
console.log('other');
break;
}在上面代码中可以看出 switch case 比 if else 代码行数还多，break 关键字也是必不可少，还不忘写 default。这里我们推荐用 Object 或 Map 作为条件存储。
const actions = {
1: 'processing',
2: 'fail',
3: 'success',
4: 'cancel',
default: 'other',
};
console.log(actions[status] ?? actions.default);Map 则更为强大，对象的键只能是一个字符串或符号，但 Map 的键可以是对象或更多，可以作为条件联合判断。
const actions = new Map([
[/^sign_[1-3]$/, () => 'A'],
[/^sign_5$/, () => 'B'],
//...
]);
const action = [...actions].filter(([key, value]) => key.test(`sign_${status}`));
action.forEach(([key, value]) => value());善用表达式
善用表达式，避免面条式代码。简单的条件判断可以用三元运算符代替。普通的 for 循环可以用 map、 forEach 代替。
降低复杂度
一个逻辑的代码行数越多，维护起来越困难，这个时候我们就需要将相关的逻辑抽离到另一个 function 中，从而降低上下文的复杂度。这里我们建议是一个 function 的代码量在 120 个字符的宽度下不超过一个屏幕。
值得注意的是， function 所定义的形参最好控制在 3 个以内，否则容易疏忽传入的顺序，从而变得不易维护。如果参数太多就需要将相关的参数聚合成对象传递。
移除重复代码
重复代码在 Bad Smell 中排在第一位，所以，竭尽你的全力去避免重复代码。因为它意味着当你需要修改一些逻辑时会有多个地方需要修改。
引入顺序
在 import 中，我们约定将 node_modules 中的包放在前面，然后是相对路径的包。有时一个 css 的 import 顺序不同就会导致执行的优先级不同。
使用声明式
声明式编程：告诉“机器”你想要的是什么(what)，让机器想出如何去做(how)。命令式编程：命令“机器”如何去做事情(how)，这样不管你想要的是什么(what)，它都会按照你的命令实现。世界很美妙，远离命令式，节省时间体验生活。
// 声明式：筛选我需要的结果
const result = dataSource.filter((dataItem) => dataItem.age > 10);
// 命令式：亲力而为查找/追加数据
let result = [];
dataSource.forEach((dataItem) => {
if (dataItem.age > 10) {
result.push(dataItem);
}
});这个时候有人就会说命令式编程性能好。其实我们写代码无需做过早优化，那点性能损耗与可维护性比起来可以算是九牛一毛。
写好业务注释
优秀的代码命名无需注释，代码即注释，加上注释就会冗余。这时某个业务的逻辑就离不开准确的注释，这样可以帮助我们更加理解业务的详细逻辑。需要要求的是代码改动注释也要随之更新。
函数式编程
函数式编程获得越来越多的关注，包括 react 都遵循这个理念。
函数是”第一等公民”
变量可以一个函数，可以作为另一个函数的参数
function increaseOperator(user) {
return user.age + 1;
}
userList.filter(Boolean).map(increaseOperator);纯函数
即相同输入，永远会得到相同输出，而且没有任何可观察的副作用。如果使用了 setTimeout 、Promise 或更多具有意外情况发生的操作。那么这类操作被称之为 “副作用” Effect。
每一个函数都可以被看做独立单元。纯函数的好处：方便组合、可缓存、可测试、引用透明、易于并发等等。
// 不纯的， minimum 可能被其他操作改变
let minimum = 21;
function checkAge(age) {
return age >= minimum;
}
// 纯的
function checkAge(age) {
const minimum = 21;
return age >= minimum;
}比如 slice 和 splice， slice 符合纯函数的定义是因为对相同输入它保证能返回相同输出。而 splice 却会改变调用它的数组，这就会产生可观察到的副作用，即这个原始数组永久地改变了。
var countList = [1, 2, 3, 4, 5];
// 纯的
countList.slice(0, 3);
//=> [1, 2, 3]
countList.slice(0, 3);
//=> [1, 2, 3]
// 不纯的
countList.splice(0, 3);
//=> [1, 2, 3]
countList.splice(0, 3);
//=> [4, 5]不可变数据
每次操作不修改原先的值，而是返回一个新的值，这与无副作用相呼应。不可变数据模型易于调试，不用担心当前数据被别的地方更改。
// Bad 修改了参数
function updateUser(user) {
user.age = 10;
}
// Good 返回新的对象
function updateUser(user) {
return {
...user,
age: 10,
};
}这里推荐 immer 作为函数式不可变数据操作。
完善的 TS 类型
typescript 拥有强大的类型系统，弥补了 javascript 在类型上的短板。我们在写 typescript 代码的时候需要注意的是，不使用隐式/显示的 any 类型，若有不确定类型的情况，首先考虑的是 泛型 去约束它，其次则用 unknown 加断言，最后才是 any。
// 典型类型完备的函数
function pick<T, K extends keyof T>(obj: T, keys: K[]) {
return Object.fromEntries(keys.map((key) => [key, obj[key]])) as Pick<T, K>;
}
pick(userInfo, ['email', 'name']);结合 prettier + eslint
在团队协作中，统一的代码尤为重要，目前社区中的 eslint 规则层出不穷。其中 eslint-config-airbnb 限制最为严格，很多开源团队都在用。这里我们可以与 prettier 搭配用，并禁用其中互相冲突的规则。编码指南 https://github.com/airbnb/javascript
结语
想写出优雅的代码其实很简单，千里之行，始于足下。我们需要不断优化自己的代码，不要畏惧改善代码质量所需付出的努力。理解这些准则并实践，假以时日，相信我们每个人写代码都能做到像写诗一样行云流水。
