代码风格建议

一、变量相关

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，加快效率，也是对个人的一种提升。与君共勉。