如何写好你的JavaScript【推荐】

前言

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

结语

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

以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,同时也希望多多支持我们!

(0)

相关推荐

  • Node.js编码规范

    调用函数的时候,函数名与左括号之间没有空格. 函数名与参数序列之间,没有空格:所有其他语法元素与左括号之间,都有一个空格. 使用小驼峰式命名法作为所有变量和属性的命名规则. 缩进使用两空格,统一使用单引号. 关联数组,除非键名中有空格或是非法字符,否则一律不用引号. 不要将不同目的的语句,合并成一行. 不要省略句末的分号,哪怕一行只有一个语句. 不要使用自增(++)和自减(--)运算符,用+=和-=代替. 不要使用"相等"(==)运算符,只使用"严格相等"(===)

  • JavaScript 程序编码规范

    软件的长期价值直接源于其编码质量.在它的整个生命周期里,一个程序可能会被许多人阅读或修改.如果一个程序可以清晰的展现出它的结构和特征,那就能减少在以后对其进行修改时出错的可能性.编程规范可以帮助程序员们增加程序的健壮性. 所有的JavaScript代码都是暴露给公众的.所以我们更应该保证其质量.保持整洁很重要. JavaScript文件 JavaScript程序应独立保存在后缀名为.js的文件中. JavaScript代码不应该被包含在HTML文件中,除非这是段特定只属于此部分的代码.在HTML

  • JavaScript之编码规范 推荐

    一.命名 1.应给变量和函数取一个含义确切的名称,不要随意命名. 2.非构造函数采用驼峰命名法,尽量采用动宾结构,以与变量名相区别,如getName或IsFull.构造函数(即自定义类型)名称首字母大写,以与非构造函数相区别,如Person. 3.变量采用驼峰命名法.由于JavaScript是一种弱类型语言,因此建议在变量名称前加前缀:整形(i),浮点数(f),布尔型(b),字符串(s),数组(a).但不强制这么做,可根据个人爱好选择,选择好后就不要混用加前缀和不加前缀这两种方式了. 二.布局

  • 浅谈JavaScript编程语言的编码规范

    JavaScript 编程语言作为最流行的客户端脚本语言,早已被众多 Web 开发人员所熟悉.随着 Web2.0 时代的到来和 Ajax 技术的广泛应用,JavaScript 也逐渐吸引着更多的视线.工作中要求越多的是对 JavaScript 语言的深入学习,灵活运用,和对编码质量的保证. 对于熟悉 C/C++ 或 Java 语言的工程师来说,JavaScript 显得灵活,简单易懂,对代码的格式的要求也相对松散.很容易学习,并运用到自己的代码中.也正因为这样,JavaScript 的编码规范也

  • 最全的Javascript编码规范(推荐)

    1.嵌入规则 Javascript程序应该尽量放在.js的文件中,需要调用的时候在页面中以<script src="filename.js">的形式包含进来.Javascript代码若不是该页面专用的,则应尽量避免在页面中直接编写Javascript代码. 2.对齐缩进与换行 a) 缩进 在同一系统中应采用同一种缩进标准,本文提倡缩进大小为4个空格.各编译器对Tab键所代替的空白大小定义不同.建议在设置开发环境时,将编辑器里的Tab快捷键重新设置成4个空格.多数编译器提供了

  • 前端编码规范(3)JavaScript 开发规范

    JavaScript规范 变量声明 总是使用 var 来声明变量.如不指定 var,变量将被隐式地声明为全局变量,这将对变量难以控制.如果没有声明,变量处于什么定义域就变得不清(可以是在 Document 或 Window 中,也可以很容易地进入本地定义域).所以,请总是使用 var 来声明变量. 采用严格模式带来的好处是,当你手误输入错误的变量名时,它可以通过报错信息来帮助你定位错误出处. 变量名 变量名推荐使用驼峰法来命名(camelCase) 全局变量为大写 (UPPERCASE ) 常量

  • 使用C# 的webBrowser写模拟器时的javascript脚本调用问题

    感觉很久不写模拟器代码了,昨天调试的时候碰了点壁,记录下来,避免大家再跟我犯同样的错误. 加入Javascript脚本的地方: HtmlElement jsElement = webBrowser1.Document.CreateElement("script"); jsElement.SetAttribute("type", "text/javascript"); jsElement.SetAttribute("text",

  • 一篇文章教你写出干净的JavaScript代码

    目录 1. 变量 使用有意义的名称 避免添加不必要的上下文 避免硬编码值 2. 函数 使用有意义的名称 使用默认参数 限制参数的数量 避免在一个函数中做太多事情 避免使用布尔标志作为参数 避免写重复的代码 避免副作用 3. 条件语句 使用非负条件 尽可能使用简写 避免过多分支 优先使用 map 而不是 switch 语句 4.并发 避免回调 5. 错误处理 6.注释 只注释业务逻辑 使用版本控制 总结 一段干净的代码,你在阅读.重用和重构的时候都能非常轻松.编写干净的代码非常重要,因为在我们日常

  • 如何写好你的JavaScript【推荐】

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

  • 「中高级前端面试」JavaScript手写代码无敌秘籍(推荐)

    1. 实现一个new操作符 new操作符做了这些事: 它创建了一个全新的对象. 它会被执行[[Prototype]](也就是__proto__)链接. 它使this指向新创建的对象.. 通过new创建的每个对象将最终被[[Prototype]]链接到这个函数的prototype对象上. 如果函数没有返回对象类型Object(包含Functoin, Array, Date, RegExg, Error),那么new表达式中的函数调用将返回该对象引用. function New(func) { va

  • 写给想学习Javascript的朋友一点学习经验小结

    当然只是个人的经验,有什么不对的也请高手见谅和指正. 关于到培训学校学习的忠告:别说现在没有这样的学校,就是有专门的学校也不要去,因为不会有好的老师的.不要浪费你自己(很可能是你父母)的钱和时间.趁早死了这个念头. 关于培训学校的这个我想我要比一般的朋友更有发言权,因为我本人干英语培训将近2年,我很清楚培训市场的情况,你很难碰到一个好的老师.英语可能还好些,毕竟英语说得好的老师还比较多,长期跟老外泡在一起,确实对口语能力的提高很显著,但是代价是很昂贵的.而你现在要学的是Javascript,呵呵

  • 写给小白的JavaScript引擎指南

    关于本文标题,我并不认为参与写或者读本文的人是白痴.但是有时某个话题会让你觉得自己就像个白痴一样,而 JavaScript 引擎就是这些话题之一,至少对于我来说是这样. 有时编写 Web 应用的代码会感觉充满魔力,因为我们只是写了一系列字符,就能在浏览器里看到效果了.但是理解魔法背后的技术,可以帮助你更好地提高编程技巧.至少当你试图解释在 JavaScript 驱动的 web 或移动应用的幕后发生了什么的时候,会觉得自己不那么白痴了. 很多年前,那是我还是个研究生讲师,向一个教授抱怨还没有掌握那

  • 如何写一个通用的JavaScript效果库!(1/2)

    JavaScript的动态效果最基本的是 动态改变大小,移动位置,改变透明度,改变颜色等等. 而其他一些比较炫的效果无非是对这些最基本效果的组合和运用. 现在网上已经有很多很不错的优秀Javascript库或者效果库,我们是否有必要再造轮子呢? 放眼望去,Yahoo UI, 基于Prototype的scriptaculous, Rico, JQuery, Dojo,还有很多很多. 这些库都带有很不错很优秀的动态效果.我们可以直接使用. 但是对于一些中小型项目来说,只是偶尔用到一两个特效,就没有必

  • 分享一个自己写的简单的javascript分页组件

    自己写的一个简单的分页组件,主要功能还有实现都在JS中,html页面中只用增加一个放置生成分页的DIV,并给定容器的id. html结构如下: 复制代码 代码如下: <ul class="pagination" id="pageDIV"> </ul> class="pagination" 给定了分页的样式, id="pageDIV"用于放置JS生成的分页 CSS结构如下: 复制代码 代码如下: .pag

  • 如何写一个通用的JavaScript效果库!(2/2)

    在上个随笔中贴出了效果库的整体框架,和一个简单的opacity插件. 今天这个随笔主要是扩展其他常用 效果插件,毕竟框架只能是个空壳,内容还是要自己充实. 如果看过了我上篇的实现细节,这里就不多说废话了,来段代码先: 复制代码 代码如下: /**//****************************************************/  // 移动, 这里是move to  就是移动到 x,y 当然,大家也可以再扩展一个move by  移动x个象素  Effect.Init

  • 如果你想写自己的Benchmark框架(推荐)

    简介 使用过JMH的同学一定会惊叹它的神奇.JMH作为一个优秀的Benchmark框架带给了我们无数的欢乐.作为一个有极客精神的程序员,那么有没有想过去自己实现一个Benchmark框架呢? 在实现Benchmark框架的时候有需要注意些什么问题呢?快来一起看看吧. 八条军规 这里叫军规实际上不合适,只是借用一下军规的来彰显一下气势!大家不要太介意. 第一条军规 工欲善其事,必先利其器.想写好一个JMH当然需要深入了解JVM的运行原理,包括JIT,C1,C2编译器和他们的分层编译原理,JIT运行

随机推荐