这些被同事喷的JS代码风格你写过多少？

现在写代码比以前好多了，代码的格式都有 eslint、prettier、babel(写新版语法) 这些来保证，然而，技术手段再高端都不能解决代码可读性（代码能否被未来的自己和同事看懂）的问题，因为这个问题只有人自己才能解决。我们写代码要写到下图中左边这样基本上就功德圆满了。

一、变量相关

（1）变量数量的定义

NO：滥用变量

let kpi = 4;  // 定义好了之后再也没用过  
function example() {  
    var a = 1;  
    var b = 2;  
    var c = a+b;  
    var d = c+1;  
    var e = d+a;  
    return e;  
} 

YES: 数据只使用一次或不使用就无需装到变量中

let kpi = 4;  // 没用的就删除掉，不然过三个月自己都不敢删，怕是不是那用到了  
function example() {  
    var a = 1;  
    var b = 2;  
    return 2a+b+1;  
} 

（2）变量的命名

NO：自我感觉良好的缩写

let fName = 'jackie'; // 看起来命名挺规范，缩写，驼峰法都用上，ESlint各种检测规范的工具都通过，But，fName是啥？这时候，你是不是想说What are you 弄啥呢？  
let lName = 'willen'; // 这个问题和上面的一样 

YES：无需对每个变量都写注释，从名字上就看懂

let firstName = 'jackie'; // 怎么样，是不是一目了然。少被喷了一次  
 let lastName = 'willen';  
  ``` 

（3）特定的变量

NO：无说明的参数

if (value.length < 8) { // 为什么要小于8，8表示啥？长度，还是位移，还是高度？Oh,my God!!  
    ....  
} 

YES：添加变量

const MAX_INPUT_LENGTH = 8;  
if (value.length < MAX_INPUT_LENGTH) { // 一目了然，不能超过最大输入长度  
    ....  
} 

（4）变量的命名

NO：命名过于啰嗦

let nameString;  
let theUsers; 

YES： 做到简洁明了

let name;  
let users; 

（5）使用说明性的变量（即有意义的变量名）

NO：长代码不知道啥意思

const address = 'One Infinite Loop, Cupertino 95014';  
const cityZipCodeRegex = /^[^,\]+[,\s]+(.+?)s*(d{5})?$/;  
saveCityZipCode(  
  address.match(cityZipCodeRegex)[1], // 这个公式到底要干嘛，对不起，原作者已经离职了。自己看代码  
  address.match(cityZipCodeRegex)[2], // 这个公式到底要干嘛，对不起，原作者已经离职了。自己看代码  
); 

YES：用变量名来解释长代码的含义

const address = 'One Infinite Loop, Cupertino 95014';  
const cityZipCodeRegex = /^[^,\]+[,\s]+(.+?)s*(d{5})?$/;  
const [, city, zipCode] = address.match(cityZipCodeRegex) || [];  
saveCityZipCode(city, zipCode); 

（6）避免使用太多的全局变量

NO：在不同的文件不停的定义全局变量

name.js  
window.name = 'a';  
hello.js  
window.name = 'b';  
time.js  
window.name = 'c';  //三个文件的先后加载顺序不同，都会使得window.name的值不同，同时，你对window.name的修改了都有可能不生效，因为你不知道你修改过之后别人是不是又在别的说明文件中对其的值重置了。所以随着文件的增多，会导致一团乱麻。 

YES：少用或使用替代方案

你可以选择只用局部变量。通过(){}的方法。

如果你确实用很多的全局变量需要共享，你可以使用vuex,redux或者你自己参考flux模式写一个也行。

（7）变量的赋值。

（编辑：ASP站长网）