一、变量相关
1、变量命名
// bad: 自我感觉良好的缩写
let fName = 'jackie' // 看起来命名挺规范，缩写，驼峰法都用上，ESlint各种检测规范的工具都通过，But，fName是啥？这时候，你是不是想说What are you 弄啥呢？
let lName = 'willen' // 这个问题和上面的一样
// good: 无需对每个变量都写注释，从名字上就看懂
let firstName = 'jackie'
let lastName = 'willen'
// bad: 命名过于啰嗦
let nameValue
let theUsers
// good: 做到简洁明了
let name
let users
2、特定的变量
// bad: 无说明的参数
if (value.length < 8) { // 为什么要小于8，8表示啥, 为啥不是4、6
....
}
// good: 添加变量
const MAX_INPUT_LENGTH = 8
if (value.length < MAX_INPUT_LENGTH) { // 一目了然，不能超过最大输入长度
....
}
二、函数相关
1、函数命名
// bad: 无法从函数名得知返回值类型
function showFriendsList() { // 不知道是返回一个数组，还是返回一个boolean值
....
}
// good: 对于返回true or false的函数，最好以should/is/can/has开头
function shouldShowFriendsList() {...}
function isEmpty() {...}
function canCreateDocuments() {...}
function hasLicense() {...}
// bad: 无法辨别函数意图
function param(json) { // param要做什么，无法得知
}
// good: 函数要以动词开头，动名结构
function convertObj2QueryString(json) {
}
2、一个函数做一件事情，不要一个函数混杂多个功能
// bad
function sendEmailToClients(clients) {
clients.forEach(client => {
const clientRecord = database.lookup(client)
if (clientRecord.isActive()) {
email(client)
}
})
}
// good
function sendEmailToActiveClients(clients) { //各个击破，易于维护和复用
clients.filter(isActiveClient).forEach(email)
}
function isActiveClient(client) {
const clientRecord = database.lookup(client)
return clientRecord.isActive()
}
3、函数中过多的采用if else ..
// bad
if (a === 1) {
...
} else if (a ===2) {
...
} else if (a === 3) {
...
} else {
...
}
// good 可以使用switch替代
switch(a) {
case 1:
....
case 2:
....
case 3:
....
default:
....
}
// good 用映射的方式
let handler = {
1: () => {....},
2: () => {....}.
3: () => {....},
default: () => {....}
}
handler[a]() || handler['default']()
// bad
function(err, results) {
if (!err) {
doOtherStuff()
doMoreStuff()
// ... etc
// ... etc
} else {
handleError(err)
}
}
// good 避免多余的Else, 尽早Return
function(err, results) {
if (err) {
handleError(err)
}
doOtherStuff()
doMoreStuff()
// ... etc
// ... etc
}
三、尽量使用ES6或ES7语法
1、连接字符串
// bad 使用传统+号
let message = 'Hello ' + name + ', it\'s ' + time + ' now'
// good 采用模板字符
let message = `Hello ${name}, it's ${time} now`
2、使用解构赋值
// bad 使用传统赋值
var data = { name: 'dys', age: 1 };
var name = data.name;
var age = data.age;
var fullName = ['jackie', 'willen'];
var firstName = fullName[0];
var lastName = fullName[1];
// good 使用结构赋值
const data = {name:'dys', age:1};
const {name, age} = data; // 怎么样，是不是简单明了
let fullName = ['jackie', 'willen'];
const [firstName, lastName] = fullName;
四、关于注释
以下情景，使用注释较好：
1、弥补代码表达意图的失败
代码本身无法说明意图，这时使用注释，说明这段代码需要被修改
2、提供信息
提供代码以外的信息，比如产品相关信息
3、复杂实现的简要概括
让阅读者快速了解某个复杂的系统
4、警示、提醒
比如某个不起眼的代码是为了解决某个 bug，防止别人误删
5、TODO
提醒某些地方有功能或者优化未做，改好后尽快删除
以下是不好的注释：
1、令人费解的注释
读懂花费的时间比看代码的时间还长
2、误导性注释，老旧的注释
代码才是真相，注释有可能是谎言，还是要“少写注释！”
3、废话注释
变量名、函数名已经很清晰，就不需要注释；因为代码会经常修改，但是注释，经常会缺乏维护，极有可能最后注释和代码本身已经相去甚远
4、注释掉的代码
没用的代码及时删除
别给糟糕的代码写注释，重构！
总结：代码整洁之道，相信有个几年经验的都会知道，但是因为种种原因，常常无法遵守。希望在今后的日子里，我们能尽量试着使自己代码的可读性和可维护性更高，这样代码质量更好，更容易定位bug，加快效率，也是对个人的一种提升。与君共勉。
网友评论