《代码规范》如何写出干净的代码（一）

// 比较差的

function handle(){}

这种我认为是比较差的，还是上面变量说的原因，范围实在太广了，通过变量名handle，我们可以知道这是一个操作，但是具体什么操作就完全不知道了，很明显，这个不大合适；

// 正常

function save(){}

这种就相对要好一些，我们知道这是一个保存的函数，但是在写的过程中也许我们能知道这是保存什么，但是过了一段时间后，光看名字我们只能知道这是一个保存操作，具体保存什么就完全不得而知了；

相比handle，save的优点在于，具体能知道这是一个操作的类型了，只是说这个操作是对什么操作的，不得而知；

function saveUser(){}

明显的，这个意图就比较明确了，就是保存用户，因此这种事比较合适的，比较优秀的命名；

class类

---

对于class类，我感觉最大的用处是用来构建抽象事物，比如用户，产品，对于这种我感觉它的规则其实可以和变量差不多，规则大致也是：名词 或者 短语+形容词：

// 用户

class User{}

class Customer{}

// 飞机游戏

class PlaneGame{}

对于类名，我们采用的往往是大驼峰的写法，因为定义到类往往就是构造函数；

小练习

题目：定义一个用户对象；

// 较差的

class UEntity{}

这种就是比较差的，完全看不出其意义是什么…只能感觉说是U的一个实体，猜不出；

// 普通的

class UserObj{}

这种就是很普通的，看名字我们能知道这是一个关于用户的obj集合，但是又有点冗余

class User{}

class Admin{}

这种就很好，看名字能直接知道其作用，Admin的话是User的具体权限划分，有时候我们需要更具体的用户信息，因此完全可以采用更具体化的名字来代表；

其他

---

对于变量的描述不太建议超过3个单词，比如

// 不太建议

const userWithNameAndAge = “”

这种虽然看名字我们也能很快知道其作用和意义，但是实际上总觉得太冗余了，name和age一般都是user的固定属性，实际上不太需要name和age

// 新用户

const newUser = “”;

// 已登录用户

const loggedInUser = “”;

代码结构和格式

=================================================================

注释

---

首先我们要明确一下，注释是对代码的解释和说明，目的是让别人阅读作者写的代码时可以更方便快捷的了解功能与业务，因此好的注释可以对协同，改BUG其事半功倍的效果，不好的注释则完全是拖后腿，本来就不懂了，看了注释就更加模凌两可…

不好的注释

直接看示例吧

// 冗余的注释

function getUserName(type) {

if (type === “first”) {

// 如果type的值等于first返回first name

return “first name”;

} else {

// 否则返回last name

return “last name”;

}

}

这种，有什么不好？很明显就是不看注释我们也一样能很快的明白代码的含义，而一旦写了注释，我们就需要花额外的精力去阅读，这个就不大合适了，注释的本意是协助更快的阅读，这边则有点本末倒置了；

第二种注释也是比较讨厌的，就是变量名的命名和注释是冲突的，比如

// 变量名和注释冲突

function insertUser(user) {

this.dbEngine.insert(user) // 更新用户

}

就是类似与这种，insert我们一般代表的是插入，而这里的注释写的却是更新，更新一般使用的单词是update，因此其他开发人员一旦看到这个注释，就不得不去看具体的实现逻辑，判断这个方法到底是插入还是更新，因此注释一定要和变量名相合，不能产生误导；

第三种注释，则是注释掉的代码，这个其实挺无奈的，随着项目越来越大，当时不确定的代码临时注释掉了，可能当时的本意是有另外的解决方案，但不一定对，注释掉的代码需要暂时保存，但是随着开发进度的深入，注释掉的代码往往会被永远保留，而对接手的人，则不敢随意删除，因此在这种情况下一般有两个推荐：

• 代码review的时候务必审查注释掉的代码，发现后审查情况，判断是否需要删除；

• 功能一旦确定，开发人员自己就要有意识的去删除注释掉的代码，否则这个坑会一直被保留下去；

好的注释

有不好的，那肯定就有好的，好的注释一般有以下几种：

1. 版权信息，包括时间，版本，法律信息，作者信息等等，这些信息可以快速帮助其他人有问题时联系作者；

2. 对变量名的补充，比如变量名无法描述的信息，

// 邮箱 [text]@[text].[text]，邮箱只有一个"@“和一个”."

const emailRegex = /\S+@\S+.\S+/

3. 警告信息的描述，比如一些代码有适用性或者功能上的注意点，那么可以通过注释来表达

// 仅使用于浏览器环境

localStrage.setItem(“user”,“name”)

4. 未完成的代码，比如当时写代码时因特殊原因未写完，那么可以写个注释提醒一下

function getUser(){

// 待办事项，需要实施

}

代码格式

---

代码格式简单的来说分为两种，一种是行与行之间的（比如行与行的空行），一种是同一行之间的（比如缩进），但是不管怎么样，我们的目的都是为了提高可读性；

行与行

行与行之间的代码，原则上不能有太多的跳跃，简单的说就是不要让人来回滚动，为了达到这个目的，我们一般会有以下几点考虑

• 考虑将具有多个概念的文件进行拆分，比如一个文件中存在好多个class类，那么此时就可以考虑将每个class作为一个文件进行拆分；

• 同一个文件中，不同的“区域”应该用间隔分开，比如一个大的功能界面里面有新增和修改两块功能，那么新增相关的应该写在一起，修改相关的也应该写在一起；

• 同一个文件中，相关的功能应该尽量靠近，比如新增和查询，一般我们针对表格的内容在新增成功后都会需要刷新表格内容，那么如果此时这两块区域离的非常远，那么就会对我们的阅读造成不便，比如下例：

// 起始

function start(){

next()

}

// 下一步

function next(){

last()

}

// 结尾

function last(){}

这种相对就比较合理，功能是按着顺序书写的，那么阅读的时候也就可以按着顺序阅读，极大的方便了我们的理解；

同一行

个人觉得同一行的规则中最主要的一点就是：代码行在不水平滚动的情况下能正常阅读，也就是尽量不要出现滚动条，一般而言我们会有以下几条规则约定：

• 缩进，关于缩进需要根据团队的实际情况而定，一个tab2个空格或者4个空格都可以；

• 将长语句拆分为多个短语句，这个拆分会有助于阅读理解；

小结

============================================================

本文中第一小节从变量，函数，class类等的命名规则阐述了如何编写才能方便阅读，方便理解，第二小节则从注释到代码格式来描述开发时的一些注意点，总体小结大致如下：

• 变量，函数，class类的命名规则可以使用：名词 或者 短语+形容词来描述；
• 好的注释可以给阅读者在阅读代码时进行补充和帮助快速理解，过多的注释以及误导性的注释都是会大大增加理解成本；
• 代码的的行与行之间需要判断上面一个区域于下面一个区域是否有一定的关联性，如果有那么则不需要分开，如果没有则需要进行空行分格；

最后

在面试前我花了三个月时间刷了很多大厂面试题，最近做了一个整理并分类，主要内容包括html，css，JavaScript，ES6

真题解析、进阶学习笔记、最新讲解视频、实战项目源码、学习路线大纲
详情关注公中号【编程进阶路】

，计算机网络，浏览器，工程化，模块化，Node.js，框架，数据结构，性能优化，项目等等。

包含了腾讯、字节跳动、小米、阿里、滴滴、美团、58、拼多多、360、新浪、搜狐等一线互联网公司面试被问到的题目，涵盖了初中级前端技术点。

• HTML5新特性，语义化

• 浏览器的标准模式和怪异模式

• xhtml和html的区别

• 使用data-的好处

• meta标签

• canvas

• HTML废弃的标签

• IE6 bug，和一些定位写法

• css js放置位置和原因

• 什么是渐进式渲染

• html模板语言

• meta viewport原理