「转」你必须学会编写优秀的 JS 代码之编程习惯

引言

一图胜千言，给大家先看一张代码量的对比图：

代码量随时间的变化

得出结论：

• 糟糕的代码设计会让我们在前期写很少的代码，就能实现很多需求，但是后期，代码量随时间的变化会发生指数级的增长，我们将会有很繁重的任务。
• 优秀的代码设计会让我们在前期做很多的操作，但是后期的时候，只需要很少的代码就能实现需求，代码量增长的速度也会很慢，我们会有很多的空闲时间做自己喜欢的事。

所以，我相信不会有人喜欢做繁重的任务，为了写出优秀的代码，我们除了要养成良好的编程习惯外，还要不断的去学习更优秀的代码结构和编程方式。

在分享自己的技术经验之前，先告诉大家，我不会写诸如 缩进层级，行的长度，换行空行，注释，文档注释，花括号对齐方式 等方面的规范，不是因为它们不重要，而是因为这不是决定代码质量的核心因素，而且没有统一规范，各大公司采用的标准都有差异，所以这些因素不在本篇文章的范围内，如果大家需要，我会在后期文章中专门写一篇关于这些规范的文章，有需要的请私信我。

进入正题

我会从 2 个方面（编程习惯，代码结构）来概述 。

编程习惯

• 异常处理
  如果你没有使用异常处理的习惯，这可能是因为你并未真正的理解它的作用。当你正确使用异常处理之后，你会发现你的代码最显著的变化就是：少了 很多的 if-else 语句 。虽然在 JS 中，只有错误（Error），没有异常（Exception），但是我们很多人还是喜欢将之成为异常( 我觉得并没什么不好，反而 会更形象)，js 把 异常分为以下6种：

  EvalError: raised when an error occurs executing code in eval()
  RangeError: raised when a numeric variable or parameter is outside of its valid range
  ReferenceError: raised when de-referencing an invalid reference
  SyntaxError: raised when a syntax error occurs while parsing code in eval()
  TypeError: raised when a variable or parameter is not a valid type
  URIError: raised when encodeURI() or decodeURI() are passed invalid parameters

  但是很多人都以为只能使用这6种异常，不符合项目中的需求，所以就不使用异常处理了，但其实我们完全可以根据自己的项目去自定义一些异常，我建议大家在错误消息中包含函数名称以及失败的原因，这样会十分利于你的代码调试，如图：

  自定义异常处理
  

  为了便于统一管理，我建议大家自己建立一个异常模块，需要的时候，直接引入这个模块，如图：

异常模块

大家如果不习惯使用 异常处理 的话，我的建议是从你的下一个项目开始，你就试着去用异常处理，你会发现你的代码非常优雅，省去很多的 if-else，十分干净利落。

• 事件处理

  有经验的开发者一定会知道，随着项目内容增多的时候，代码里面的事件处理程序会特别多，如果没有良好的管理，应用逻辑会和事件处理程序紧密的耦合在一起，而且这时的代码会有很大的冗余。为了解决这种问题，我建议大家采用以下3个方法：

  1. 隔离应用逻辑：将应用逻辑从所有事件处理程序中抽离出来是最佳的方法，因为你不知道接下来什么时候还会触发同一段的逻辑。
  隔离应用逻辑
  2. 禁止分发对象：既然应用逻辑和事件处理程序是完全隔离的，那么应用程序中就不能有任何与事件有关的代码，所以，应用逻辑不能依赖于 event 对象来实现某一功能。
  禁止分发对象
  3. 定义事件注册模块：整个时代都在提倡 js 代码统一模块化管理，所以，为了方便管理，我们有必要定义一个事件注册模块，用来统一完成事件的注册( 绑定 ) 和 移除
  事件注册模块

• 配置分离
  每一次修改源代码，都会有引入 bug 的风险，且只修改一些数据也会带来许多意外的风险，因为数据是不影响指令正常运行的，精心设计的应用应该把关键数据从源码中抽离出来，这样，我们每次修改时，只需要修改抽离出的那部分代码就行了，这样既简单方便又降低了很多风险。什么是配置数据呢？就是在应用中写死了的那些值，如图的代码：

  "/write.php"就是配置数据

  "/write.php"就是配置数据，想象一下，这只是一个文件中的代码，如果有100个文件中有这样的代码，假设某天，网站的 write.php 改成了 compose.php ，那么你就要将 "/write.php" 改100次 ！ 所以，无论是从安全上讲还是从可维护上讲，我们都很有必要抽离出配置项，并且定义在 Config 配置模块中。（需要自己自定义一个 Config 配置模块，代码就不用演示了吧。。。）

• 其他

  1. 将 CSS 代码从 JS 代码中抽离出来（推荐 使用 class 类名作为 CSS 和 JS 通信的桥梁）
  2. 将 JS 代码从 HTML 标签中分里出来( 不要使用<span onclick="dosomething()" ></span>）。
  3. 将 HTML 从 JS 中抽离出来 。这里特别说一下，有些人可能会习惯了在 JS 代码中 这样写：$( "p" ).append( '<h2>大家好</h2>' )，这样并不是不可行，但是当需要插入大量的 HTML 标签时，代码就会变得十分丑陋而且难以维护，我们可以使用以下方法来解决这个问题：
  • 使用 Jquery 的 load( "路径" ) 方法 从服务端加载 。
  • 使用<script type="text/html"> 在这里书写你的 HTML 代码 </script>。

结束

我突然发现本篇内容写的有点多了，所以 “代码结构” 这部分只能留到下一篇文章再讲了，我担心文章太长会让人没有耐心 ，其实就连本篇，我都感觉很多东西还没讲，但是因为长度原因，只能先搁置了。再说一下，下一篇文章，我再将本篇没有讲的 “代码结构” 部分好好讲一讲。

有什么地方不完善，出错，或者是漏掉的，请大家给我留言，私信，我会及时修改的。在编程的道路上，希望大家都坚持下去，加油，共勉！！！