<<编写可维护的JavaScript>>之避免使用全局变量

一、避免全局变量的理由

js中避免创建全局变量一是避免命名冲突,二是避免因为创建全局变量让代码变得脆弱,三是创建全局变量会让代码难以测试。

二、避免创建全局变量的几种方法

//避免全局变量 避免命名冲突
//1.单全局变量之命名空间
var YourGlobal = {
	namespace: function(ns) {
		var parts = ns.split("."),
		object = this,
		i, len;
		for (i=0,len=parts.length;i < len; i++) {
			if(!object[parts[i]]) {
				object[parts[i]] = {};
			}
			object = object[parts[i]];
		}
		return object;
	}
};

YourGlobal.namespace("Books.MaintainableJavaScript");
YourGlobal.Books.MaintainableJavaScript.author = "youyi";
YourGlobal.namespace("Books.HighPerformanceJavaScript");
//保持上面的YourGlobal.Books.MaintainableJavaScript原封不动
YourGlobal.Books.HighPerformanceJavaScript.name = "王宝强";
console.log(YourGlobal.Books.MaintainableJavaScript.author);//youyi
console.log(YourGlobal.Books.HighPerformanceJavaScript.name);//王宝强
//在方法调用之后立即给它添加属性
YourGlobal.namespace("Books").ANewBook = {};

//2.单全局变量之模块
//YUI模块 是将模块和命名空间概念合并在一起
YUI.add("my-module",function(Y) {
	//添加命令空间
	Y.namespace("Person.MaintainableJavascript");
	Y.Person.MaintainableJavascript.author = "xiaoma";
},"1.0.0",{requires:["dependency1","dependency2"]});

//YUI().use()传入想加载的模块名称来使用模块
YUI().use("my-module","another-module",function(Y) {
	console.log(Y.Person.MaintainableJavascript.author);
});

//异步模块 AMD
define("my-module2",["dependency1","dependency2"],function(dependency1,dependency2) {
	var Books = {};
	Books.MaintainableJavaScript = {
		author: "张歆艺"
	};
	return Books;
});

//AMD模块可以是匿名的,模块加载器可以将JavaScript文件名当作模块名称,所以如果有一个叫my-module2.js的文件,模块可以只通过模块加载器来加载

define(["dependency1","dependency2"],function(dependency1,dependency2) {
	var Books = {};
	Books.MaintainableJavaScript = {
		author: "张歆艺"
	};
	return Books;
});

//模块加载器
//1.使用AMD模块,需要一个与之兼容的模块加载器(Dojo),用Dojo可以向下面这样来加载
//Dojo同样自己也封装了AMD模块
var books = dojo.require("my-module2");
console.log(books.MaintainableJavaScript.author);

//2.RequireJs指定依赖和回调函数
//Jquery和Dojo都可以使用RequireJs来加载AMD模块
require(["my-module2"],function(books) {
	console.log(books.MaintainableJavaScript.author);
});

//零全局变量
//特殊情况下才会使用,脚本很短且不需要和其他代码产生交互的情况下使用
(function(win) {
	//"use strict"严格模式,避免创建全局变量
	var doc = win.document;
	//其他变量
	//其他相关代码
});

  

时间: 2024-08-04 05:22:31

<<编写可维护的JavaScript>>之避免使用全局变量的相关文章

编写可维护的JavaScript之简易模版

/* * 正则替换%s * @para arg1(text) 需要替换的模版 * @para arg2 替换第一处%s * @para arg3 替换第二处%s * 返回替换后的字符串 */ var sprintf = function (text) { var i = 1, args = arguments, len = args.length; return text.replace(/%s/g, function () { return (i < len) ? args[i++] : &quo

《编写可维护的javascript》读书笔记(上)

最近在读<编写可维护的javascript>这本书,为了加深记忆,简单做个笔记,同时也让没有读过的同学有一个大概的了解. 一.编程风格 程序是写给人读的,所以一个团队的编程风格要保持一致. 1.缩进:一种是利用制表符缩进,一种是使用空格符缩进,各有利弊,任选一种,保持一致即可.个人比较喜欢制表符缩进. 2.语句结尾需要加上分号,避免没必要的BUG. 3.命名:首先要语义化,使用驼峰式命名法,小驼峰即首字母小写,之后每个单词首字母大写:大驼峰即首字母大写,之后同小驼峰:变量名前缀应该是名词(my

编写可维护的JavaScript之事件处理

规则1:隔离应用逻辑 这会让你的代码容易调试 规则2:不要分发事件对象 event对象包含了太多信息 // a good example var handlePopup = { // 事件句柄,处理所有和event对象有关的东西 handleClick: function (e) { // 假设事件支持DOM Level2 e.preventDefault(); e.stopPropagation(); // 传入应用逻辑 this.showPopup(e.clientX, e.clientY)

《编写可维护的javascript》读书笔记(中)——编程实践

上篇读书笔记系列之:<编写可维护的javascript>读书笔记(上) 上篇说的是编程风格,记录的都是最重要的点,不讲废话,写的比较简洁,而本篇将加入一些实例,因为那样比较容易说明问题. 二.编程实践 1.UI松耦合 第一.将css从javascript中抽离(要改变dom样式数据,应该去操作dom的class名而非dom的style属性,后续要修改此样式只需到对应的css文件中修改而不用修改js文件): 第二.将javascript从HTML中抽离,比如下面的写法是不好的 <!-- 不

编写可维护的Javascript纪要

第一部分: 编程风格 在大型项目开发中,因为项目可读性规范性的需要(就像<编写可维护性的Javascript>一书作者Nicholas Zakas大神所说,他们团队所有成员写出的代码就像是经同一个人之手写出的一样),风格约定要大于个人喜好这一点毋庸置疑,不过什么样才是好的编程风格约定?下面推荐一些实践中沉淀下来的代码规范和最佳实践: 缩进 缩进问题和编辑器问题一样是一个因为个人喜好和其他不管值得不值得争执的理由而存在争议的问题,目前存在两个流派,空格流和tab流.个人比较习惯于tab(4个空格

读《编写可维护的JavaScript》第六章总结

第六章 避免使用全局变量 JavaScript执行环境在很多方面都有其独特之处,全局变量就是其中之一.“全局变量”是一个神秘的对象,它表示了脚本的最外层上下文. 在浏览器中,windows对象往往重载并等同于全局对象,因此任何在全局作用域声明的变量和函数都是windows对象的属性. 6.1 全局变量带来的问题 这个就不用照着书详谈了,当我们进入团队合作编写代码时,若大家自定义的变量都是直接挂载在windows对象上(也就是全局变量),很容易发生命名冲突.像这样: function sayCol

《编写可维护的Javascript》总结

最近读了这本书,为了防止狗熊掰棒子式的学习,写这篇总结把收获沉淀下来. 先说说看书的一点感受吧.不要说在大公司中多人团队合作了,就连原来在实验室的几个人小规模开发也都很需要编码规范,否则当复用组件的时候就要花费大量的时间调试,甚至不得不更改原来的代码.多人协作所需要制定的代码规范,常常就是大家达成协议要缩进几个格.如何命名等这些编程风格.虽然这个也很重要,统一风格有助于别人读懂和维护代码,而我认为更重要的是减少对他人代码的污染,同时减少重复的逻辑,能够实现代码的复用.再往上走,更高级和智能的应该

《编写可维护的JavaScript》读书笔记(一)

第一章主要讲的是编程风格部分的基本格式化. 一个严格按照一定规范来编写的项目,无论从可读性,可维护性,或者运行性能上来说,都是比无规范项目更胜一筹的. 基本的格式化包含以下几种: 1.缩进层级 良好的缩进能让多位开发人员更快的读懂代码,提高工作效率. 至于如何缩进,其实并没有一个统一的共识,但是在空格缩进和制表符缩进中,我主张制表符缩进,原因很简单:按钮数少. 2.语句结尾 说到语句结尾,其实在javascript中最常见的就是加不加分号,什么时候加分号的问题. 依赖于js分析器的自动分号插入(

读《编写可维护的javascript》笔记

第一章 基本的格式化 缩进层级:推荐 tab:4; 换行:在运算符后面换行,第二行追加两个缩进: // Good: Break after operator, following line indented two levels callAFunction(document, element, window, "some string value", true, 123, navigator); // Bad: Following line indented only one leve