关于

微信公众号：前端呼啦圈（Love-FED）
我的博客：劳卜的博客
知乎专栏：前端呼啦圈

前言

在实际工作中，我们应该经常会看到一些功能上没有问题，但编码风格和规范却十分糟糕的代码，这往往会让人不敢再往下阅读，甚至会影响阅读者一天的心情。这些代码不仅不易阅读，而且难以维护，它们一般会出自刚入门的编程新手，也会出自工作了好几年的老程序员手下。因此本文的目的在于帮助那些没有养成良好的编码风格，缺乏相应编码规范意识的JavaScript学习者们改善他们的编码形象。

编码形象

以上我提出了编码形象的概念，我个人认为：

编码形象 = 编码风格 +　编码规范

一个良好的编码形象就等于一个穿着得体的青年，对于程序员来说这是同行了解你优秀能力的最直接最简单的方式。

我们来看一下一段糟糕的编码形象：

//打个招呼
function func(){
    var age=18,sex='man';
    var greeting='hello';
    if(age<=18&&sex=='man'){
        console.log(greeting+'little boy')
    }

    ...
}
func()

上方代码整体缩在了一起，缺乏规范意识，阅读体验很差，不忍直视。

再来看一段良好的代码形象：

// 打个招呼
function greetFn() {
    var age = 18,
        sex = 'man',
        greeting = 'hello';

    if (age <= 18 && sex === 'man') {
        console.log(greeting + 'little boy');
    }

    ...
};

greetFn();

上方的代码是不是感觉舒服多了？

由此可见养成一个良好的编码形象是至关重要的，而本文主要讲解的是基于JavaScript的编码形象，即基于JavaScript的编码风格和编码规范。

那么什么是编码风格，什么是编码规范，两者的区别又是什么？

编码风格

首先编码风格既然是风格，就没有对错之分。就好比每个人的穿着打扮不同，有的人穿的比较得体，有的人穿的比较随意而已。

而在JavaScript编码风格中，也有一套比较得体的风格，尤其在团队开发中，我们不能随意的书写属于自己的风格。

下面就列举几种随意的编码风格，并将其与良好的编码风格进行对比。

1.合理注释

// 不推荐的写法
var name = '劳卜';//代码和注释之间没有间隔

if (name) {
    /*
     *注释之前无空行
     *星号后面无空格
     */
}

// 推荐的写法
var name = '劳卜'; // 代码和注释之间有间隔

if (name) {

    /*
     * 注释之前有空行
     * 星号后面有空格
     */
}

2.合理间隔

// 不推荐的写法
var name='劳卜'; // 等号和两侧之间没有间隔

// if块级语句间没有间隔
if(name){
    console.log('hello');
}

// 推荐的写法
var name = '劳卜'; // 等号和两侧之间有间隔

// if块级语句间有间隔
if (name) {
    console.log('hello');
}

3.合理缩进

// 不推荐的写法：没有合理缩进
function getName() {
console.log('劳卜'); 
}

// 推荐的写法：合理缩进
function getName() {
    console.log('劳卜');
}

4.合理空行

// 不推荐的写法: 代码功能块之间没有空行
function getName() {
    var name = '劳卜';
    if (name) {
        console.log('hello');
    }
}

// 推荐的写法：代码功能块之间有空行
function getName() {
    var name = '劳卜';

    if (name) {
        console.log('hello');
    }
}

5.合理命名

// 不推荐的写法
var getName = '劳卜'; // 变量命名前缀为动词

// 函数命名前缀为名词
function name() {
   console.log('hello');
}

// 推荐的写法
var name = '劳卜'; // 变量命名前缀为名词

// 函数命名前缀为动词
function getName() {
   console.log('hello');
}

6.合理声明

// 不推荐的写法：函数在声明之前使用
getName(); 

function getName() {
    console.log('hello');
}

// 推荐的写法：函数在声明之后使用
function getName() {
    console.log('hello');
}

getName();

7.合理结尾

// 不推荐的写法：没有使用分号结尾
var name = '劳卜' 

var getName = function() {
    console.log('hello')
}

// 推荐的写法：使用分号结尾
var name = '劳卜'; 

var getName = function() {
    console.log('hello');
};

以上主要列举了7个比较常见的编码风格的例子进行了比较，在推荐的写法和不推荐的写法中两者并没有对错之分，只是推荐的写法相比较而言更容易阅读和维护，更适用于团队开发，也是良好编码形象的体现。

编码规范

对于编码规范，既然是规范，那我们就应该按照一定的规则来编写。随意编写违反编码规范的代码，可能会导致程序的出错和潜在的bug，因此其相对于编码风格来说应该更加严谨，也有人会把编码风格包含在编码规范之中。

下面就列举几个常见的实例代码：

1.比较参数

// 不推荐的写法：==和!=比较时会进行类型转换，应尽量避免使用
var num = 123;

if (num == '123') {
    console.log(num);
} else if (num != '321') {
    console.log('321');
}

// 推荐的写法：使用===和!==来进行比较
var num = 123;

if (num === '123') {
    console.log(num);
} else if (num !== '321') {
    console.log('321');
}

2.包裹if语句

// 不推荐的写法：if语句不用大话号包裹会出现潜在bug
var num = 123;

if (num === '123')
    console.log(num);

// 推荐的写法：if语句用大话号包裹
var num = 123;

if (num === '123') {
    console.log(num);
}

3.慎用eval

// 不推荐的写法：应避免使用eval，不安全，非常耗性能（一次解析成js语句，一次执行）
var json = '{"name": "劳卜", "func": alert("hello")}';

eval('(' + json + ')'); // 弹出“hello”

// 推荐的写法
var json = '{"name": "劳卜", "func": alert("hello")}';

JSON.parse(json); // 校验报错

4.判断类型

// 不推荐的写法：用typeof来判断构造函数创建的对象
var str = new String('劳卜'); 

console.log(typeof str); // 'object'

// 推荐的写法：用instanceof来判断构造函数创建的对象
var str = new String('劳卜'); 

console.log(str instanceof String); // true

5.检测属性

// 不推荐的写法：使用undefined和null来检测一个属性是否存在
if (obj['name'] !== undefined) {
    console.log('name属性存在'); // 若obj.name为undefined时则会导致判断出错
}

if (obj['name'] !== null) {
    console.log('name属性存在'); // 若obj.name为null时则会导致判断出错
}

// 推荐的写法：使用in运算符来检测对象属性是否存在，使用hasOwnProperty方法来检测不包含原型链上的对象属性是否存在
if ('name' in obj) {
    console.log('name属性存在');
}

if (obj.hasOwnProperty('name')) {
    console.log('name属性存在');
}

以上主要列举了5个常见的编码规范的例子，合理地规范自己的代码能够很大程度上减少不必要的维护成本和潜在的bug风险，对于JavaScript学习者来说应该铭记于心。

结语

“程序是写给人读的，只是偶尔让计算机执行一下。”我们不能为了贪图一时的方便而亲手毁了自己的代码形象，这会给他人和整个项目带来不必要的麻烦。

本文内容参考自《编写可维护的JavaScript》一书。

如果觉得本文对你有帮助，可以关注我的微信公众号，来这里聊点关于前端的事情。

本文对你有帮助？欢迎扫码加入前端学习小组微信群：