js工作中编写代码的规范（为了写好代码你坚持了哪些好习惯）

本文目录

• 为了写好代码你坚持了哪些好习惯
• js代码规范问题 JavaScript判断语句规范
• js代码的JS代码在优化中：
• 如何写高质量的JS，Html5前端代码
• 如何写出高效可维护并且规范的js代码
• 如何编写高质量的 JS 代码

为了写好代码你坚持了哪些好习惯

1、代码规范，易于理解。

在编写代码时，需要时刻注意使用明确定义的命名规则，具体包括易于理解的表达式变量以及明确定义的对象和库，同时也要使用规范的代码结构。这有助于帮助他人能够快速读懂你的代码，也能为未来交接工作带来便利；

2、代码复用，减少重复代码。

尽量使用最少的代码来完成所需的功能，在编写代码过程中，如果出现一处代码多处使用的情况，要考虑提出来调用；

3、记录每日的工作情况。

每天工作结束后，要进行总结一天的工作，想想今天做了哪些工作，是否充实，和计划有哪些出入，及时调整后续计划，为后续做好准备；

4、编码前先设计。

一定要想清楚后再写代码，不要急于求成，先把设计写好，如果已经开始动手但却仍不清楚自己要做什么，做一步想一步，那么就会在试验及错误身上浪费大量时间，严重的可能会跑遍，最终全部白做，需要从头再来；

5、经常备份。

好的程序员都有经常备份数据的习惯，这一点我也是在教训中学习到的，做好备份可以有效防止一些误操作导致的问题，挽回损失；

6、随时随地不断的学习。

现如今技术发展如此之快，需要不断地学习新技术。闲暇时间去阅读一些业内的技术和知识，看看网上大牛们分享的各种技术介绍和总结文章，开拓眼界，充实自身。

平时有项目做项目，把技术问题，管理问题平时多做记录，年终总结或者平时例会才不至于没有东西说。

自觉，努力学习才是王道。程序员需要学习能力。还有在软件开发中，技术变化如此之快，你花费了大量时间学习技术和工具，一旦这些技术被取代，你的知识将变得毫无价值，因为它们大部分都是实施的细节。

js代码规范问题 JavaScript判断语句规范

规范性要参考几个点：
1.是否影响效率
2.是否方便解读
3.是否便于以后维护
针对这三点去做分析就行了，如楼上所说，没有哪个人敢站出来说他写的就是规范的，但是可以通过研究一些js库去学习以形成习惯。

js代码的JS代码在优化中：

一、 让代码简洁：一些简略的表达方式也会产生很好的优化
eg：x=x+1;在不影响功能的情况下可以简写为x++;
二、 变量名方法名尽量在不影响语意的情况下简单。（可以选择首字母命名）
eg：定义数组的长度可以取名为：ArrLen而不需要取为ArrayLength。
三、 关于JS的循环，循环是一种常用的流程控制。
JS提供了三种循环：for(;;)、while()、for(in)。在这三种循环中for(in)的效率最差，因为它需要查询Hash键，因此应尽量少用for(in)循环，for(;;)、while()循环的性能基本持平。当然，推荐使用for循环，如果循环变量递增或递减，不要单独对循环变量赋值，而应该使用嵌套的++或–运算符。
四、 如果需要遍历数组，应该先缓存数组长度，将数组长度放入局部变量中，避免多次查询数组长度。
因为我们常常要根据字符串、数组的长度进行循环，而通常这个长度是不变的，比如每次查询a.length，就要额外进行一个操作，而预先把var len=a.length，则就少了一次查询。
五、 尽量选用局部变量而不是全局变量。
局部变量的访问速度要比全局变量的访问速度更快，因为全局变量其实是window对象的成员，而局部变量是放在函数的栈里的。
六、 尽量少使用eval。
每次使用eval需要消耗大量时间，这时候使用JS所支持的闭包可以实现函数模板。
七、 减少对象查找
因为JavaScript的解释性，所以a.b.c.d.e，需要进行至少4次查询操作，先检查a再检查a中的b，再检查b中的c，如此往下。所以如果这样的表达式重复出现，只要可能，应该尽量少出现这样的表达式，可以利用局部变量，把它放入一个临时的地方进行查询。
八、 字符串连接。
如果是追加字符串，最好使用s+=anotherStr操作，而不是要使用s=s+anotherStr。
如果要连接多个字符串，应该少使用+=，如s+=a;s+=b;s+=c;应该写成s+=a + b + c；
而如果是收集字符串，比如多次对同一个字符串进行+=操作的话，最好使用一个缓存。怎么用呢？使用JavaScript数组来收集，最后使用join方法连接起来，如下
var buf = new Array();for(var i = 0; i 《 100; i++){ buf.push(i.toString());}var all = buf.join("");
九、 类型转换
1. 把数字转换成字符串，应用"" + 1，虽然看起来比较丑一点，但事实上这个效率是最高的，性能上来说：("" +) 》 String() 》 .toString() 》 new String()
尽量使用编译时就能使用的内部操作要比运行时使用的用户操作要快。
String()属于内部函数，所以速度很快，而.toString()要查询原型中的函数，所以速度逊色一些，new String()用于返回一个精确的副本。
2. 浮点数转换成整型，这个更容易出错，很多人喜欢使用parseInt()，其实parseInt()是用于将字符串转换成数字，而不是浮点数和整型之间的转换，我们应该使用Math.floor()或者Math.round()。Math是内部对象，所以Math.floor()其实并没有多少查询方法和调用的时间，速度是最快的。
3. 对于自定义的对象，如果定义了toString()方法来进行类型转换的话，推荐显式调用toString()，因为内部的操作在尝试所有可能性之后，会尝试对象的toString()方法尝试能否转化为String，所以直接调用这个方法效率会更高
十、 尽量作用JSON格式来创建对象，而不是var obj=new Object()方法。
因为前者是直接复制，而后者需要调用构造器，因而前者的性能更好。
十一、 当需要使用数组时，也尽量使用JSON格式的语法，
使用JSON格式的语法即直接使用如下语法定义数组：,而不是采用new Array(parrm,param,param...)这种语法。因为使用JSON格式的语法是引擎直接解释的。而后者则需要调用Array的构造器。
十二、 对字符串进行循环操作，例如替换、查找，就使用正则表达式。
因为JS的循环速度比较慢，而正则表达式的操作是用C写成的API，性能比较好。
十三、 插入HTML
很多人喜欢在JavaScript中使用document.write来给页面生成内容。事实上这样的效率较低，如果需要直接插入HTML，可以找一个容器元素，比如指定一个div或者span，并设置他们的innerHTML来将自己的HTML代码插入到页面中。
十四、 对象查询
使用查询要比.items()更快
十五、 定时器
如果针对的是不断运行的代码，不应该使用setTimeout，而应该是用setInterval。setTimeout每次要重新设置一个定时器。
十六、 尽量减少DOM调用
在Web开发中，JavaScript的一个很重要的作用就是对DOM进行操作。可是对DOM的操作是非常昂贵的，因为这会导致浏览器执行回流 （reflow）操作。我们应该尽可能的减少DOM操作。

如何写高质量的JS，Html5前端代码

首先，本人在前端开发方面有点心得，有什么不对的地方希望给出建议让我更好的进步
1.命名
在开发前必须有个命名规范来对代码统一规范团队代码结构，使代码可读性提高
2.注释
我相信每个人看别人代码时看到密密麻麻的代码结构，相信每个人都会很头疼，即使想看也会看不下去，而且很耗时间，所以注释就变得尤其得重要，注释越清楚越详细我相信代码可维护性越高，而且更容易修改维护
3.变量
在js中变量无处不在，所以这么声明变量就变得尤其得重要，首先少使用全局变量，这样会增加加载速度，从而导致项目用户体验不好
4.声明变量如果不用 var 会导致变量成为全局变量。
5.函数
函数的参数数量
函数的参数不应该超过 3 个。如果函数的参数超过 3 个，应该将一些参数进行封装。
6.函数参数传递
只传函数需要的参数。如
// 不推荐
function greet(data){
c***ole.log(’Hello, I am ’ + data.name);
}
// 推荐
function greet(name){
c***ole.log(’Hello, I am ’ + name);
}
7.函数的功能
一个函数只做一件事。这有助于测试和代码复用。
函数尽可能无副作用。无副作用指不修改传入的参数和全局变量。
8.减少重复代码
. 记得在某个文章中看到说，如果重复的代码出现 3 次，就应该重构重复的代码。
. 松耦合
. 一个函数只做一件事
. 缓存一些计算结果
9.避免全局变量
. 从分配置和离逻辑代码
. 不要修改不属于你的对象
. 不属于你的对象包括
. 浏览器原生对象，如 Object，Array等
DOM，如 document
BOM，如 window
类库对象
如果想拓展浏览器原生对象的功能，可以创建函数，函数中把浏览器原生对象传入。如 Underscore.js 做 的那样。
10.代码风格的统一
11.尽可能的避免代码重复
. 如何减少重复的代码呢？
. 在JS中，可以将重复的代码写成一个方法，如果是可通用的，可以写在独立的JS文件中。
. 在CSS中，则需要借助Sass，Less之类的预处理语言的Mixins的功能。将重复的部分写成一个Mixins。
12.配置和逻辑分开
. JS中，对于整个站的通用配置，写在config.js里。如果是某个js的配置，在文件的开头，用defaultParam 对象来存放可变的配置，用c***t来定义不可变的配置
. CSS中，依旧要借助预处理语言。对于整站的配置，定 义在_variables.scss里。对于某个具体CSS文件里，在文件开头用变量来定义
13.减少代码的副作用
1》JS中，方法中的沟通尽量不要用全局变量；不要在Array之类的全局对象的原型链上添加方法；尽量不要定义全局的方法和变量：如果确实有很多变量，方法放在全局上，可以学习jQuery,将很多变量，方法放在一个全局对象上；自定义事件，事件的名称也要有命名空间。
2》CSS中，要做到无副作用，难度很大。对于简单页面，一个方法是，把页面上的元素都分成一个个组件，写样式时，选择器要用组件选择器 当前元素选择器。当组件变的复杂时，组件也会包含很多子组件。然后，选择器就会越来越长。。。我的解决方案是用的BEM。
14.提高代码的可读性
. 变量，方法等的合理命名，通过名称可以知道这个大概做什么的。
. 如果则要加注释来说明一下。对于不容理解的代码加注释
. 尽可能不用魔法数字
. 对于HTML，选择合适标签
15.一个方法只做一件事
一来提高代码的复用性，二来让调试也变的更容易，三来让测试变的更容易

如何写出高效可维护并且规范的js代码

设计原则：
1.原子思想：即每个function就做一件事；
2.归纳思想：将同一类的操作，全部整合到一起；
3.方便维护：可以便于后来人进行快速维护；
4.方便拓展：即可以根据每个不同的项目进行不同的更改；
5.通用前端设计模式：一些前端可以通用的设计模式
6.注意写好注释，将注释写的具体点；
具体实例
var gerry =
(function(){
//创建一个独立的对象，注入所有的方法，包括你想抛出去和不想抛出去的
var tool = {
AAAA:function(){},
BBBB:function(){
c***ole.log("我只想内部使用，不想给别人用");
}
};
/*
* 该对象承载所有需要抛出去的对象
* 1.该对象中的方法可以自己写
* 2.该对象中的方法可以注入（例子中的tempObj.tool.AA）
* 3.该对象也可以选择性抛出给使用者需要的方法，也可以隐藏（tool.BBBB）
* */
var tempObj ={
//reader为一些初始化需要的操作，有时候会有注册事件等，或者一些预操作
reader:function(){
},
//注入所有的选择器，方便选择器变化，直接修改该对象中的选择器，而不需要全局去更改
selector:{
mySelector:"#mySelector", //原密码
},
//注入所有的接口地址，方便接口变化可以进行，快速变更，不需要全局找引用的对象
inte***ce:{
loginUrl:"",
},
//注入page中所有的事件，统一管理，建议命名规范：事件_命名，例 click_login
registerEle:{
click_login:function(){
//注册单击事件
}
},
//注入所有ajax请求，页面所有请求，将在这里统一管理，建议命名规范：ajax_命名，例 ajax_login
/*
* 该请求中有2种方案,看需求使用
* 1.不公用一个请求方案
* 2.公用一个请求，但是回调处理不一样
* */
ajaxRequest:{
//不公用一个请求方案
ajax_login:function(){
$.post("","",function(data){
tempObj.callback.call_login(data);
});
},
//会有多个业务公用这个请求
ajax_login_T:function(callback){
//所有接口地址从inte***ce中获取，callback中tempObj.callback中处理
$.post("","",callback);
},
},
//处理所有回调函数，针对一个请求，处理一个回调
callback:{
//不共用请求处理回调
call_login:function(data){
//处理回调
},
//公用请求处理回调
call_login_T:function(){
var temp = function(){
};
tempObj.ajaxRequest.ajax_login_T(temp);
}
},
//所有使用的工具类，如果每个项目都单独的unit.js或者common.js等存放一些公共方法的，这里可以不使用
// PS:这里存放的只是仅针对于这个页面处理的一些tool，一般没必要抛出去，不过看业务而定
tool:{
A:function(){
c***ole.log("我是自己写的方法");
},
AA:tool.AAAA, //这是我想抛出去给别人用的东西
},
//临时缓存存放区域，仅针对本页面，如果跨页面请存放cookie或者localstorage等
//主要解决有时候会使用页面控件display来缓存当前页面的一些数据
temp:{
},
/*
* 业务使用区域，针对每个特别的业务去串上面所有的一个个原子
* 因为上面所有的方法，只是做一件事，这边可以根据业务进行串服务，很简单的
* */
firm:{
}
};
/*
* 闭包抛出去的方法
* */
var outputObj =function(){
//首先执行reader方法，初始化一些操作，比如注册事件啥啥啥的
tempObj.reader();
/*
* 抛出给别人使用的对象
* 想给别人看和使用的东西，可以注入tempObj对象，就像tool中的AA的方式
* 不想给别人看和使用的东西，就像内部tool对象中的BBBB方法，你内部可以使用，外部是无法引用的
* */
return tempObj;
}
//抛出你希望抛出去的对象，因为你掌控了所有，哈哈。
return new outputObj();
})();

如何编写高质量的 JS 代码

1、避免全局变量，因为全局变量容易发生名称上的冲突，可维护性不好。
a，使用命名空间
b，使用闭包
c，在函数内部使用var声明
2、编写可维护的代码
a.可读性
b.连续性
c.预见性
d.看起来是一个人写的
e.有文档
3、不要扩展内建的原型
扩展原型的构造函数，可以提供一些很强大的功能，但是有时候他太强大了。
有时候你会去扩展Object(),Array(),Fucntion()的原型方法，这样会导致可维护性的问题，因为这会让你的代码的移植性变差。其他的开发人员使用你的代码的时候，可能只需要原生的方法，并不需要额外的功能。
另外，你添加进去的方法，如果在循环的时候没有使用hasOwnProperty方法就会被遍历出来，这会让人很迷惑。
所以，最好还是不要扩展基本的对象。除非是下面的情况：
a.你确定在将来根据ECMAScript规范，浏览器会添加相应的原型方法，那么是可以的，你只不过是提前实现了这个功能。
b.你确定的你要实现的方法不存在–或许有时候在代码的其他的地方实现了，或者有的浏览器支持，这都是不行的。
c.有非常清晰的文档，并且与团队成员沟通过
4、避免隐藏的类型转换
Javascript在你比较两个变量的时候会进行类型的转换，这就是为什么 false == 0或者”" == 0会返回true。
为了避免这种隐藏的类型转换带来的迷惑，最好使用===或者!==操作符来比较：
5、避免使用eval()
如果在你的代码中使用eval()，那么要记住”eval() is evil”。这个方**将传入的字符串当做js代码来执行。如果代码是在运行前就确定的，那么没有必要使用eval()。如果代码是在运行时动态确定的，那么也有其他更安全的办法。例如使用方括号形式访问元素的属性：
// antipattern
var property = "name";
alert(eval("obj." + property));
// preferred
var property = "name";
alert(obj);
使用eval()还有安全问题，比如运行网络上的一段代码，而这段代码又被别人篡改了。在处理Ajax请求返回的JSON数据的时候，最好还是使用浏览器内建的处理方法，如果对于低端的浏览器不支持的，可以从JSON.org上下载对应的处理库。
6、使用parseInt()转换处理数字
使用parseInt()你可以将字符串转为数字。这个方法支持第二个表示进制的参数，常常被忽略。问题常常在处理一段以0开始的字符串的时候。在ECMAS3标准中，以0开始表示八进制，但是在ES5中又改了，所以为了避免麻烦，最好还是标明第二个参数。
7、编码规范
编码的时候遵循一定的规范，可以让代码增强可移植性，并且更加便于阅读和理解。加入团队的新人，在阅读了代码规范之后，可以更加快速的溶入团队，并理解其他人员开发的代码。
8、缩进
代码如果没有缩进，那基本上没法阅读了。比这更糟的是不规范的缩进，看着好像缩进了，但是乱七八糟摸不着头脑。所以缩进的使用必须规范。团队遵循统一的规范
9、大括号
应该使用大括号，尤其在那些可用可不用的地方，如果你的if语句或者for循环只有一句话，那么大括号不是必须的，但是这种时候最好用大括号。这可以让代码保持一致，并且便于升级。
10、命名规范
可以提高代码移植性和可维护性的一个方面是命名规范。也就是说，在取变量名的时候总是采取一贯的做法。
11、写注释
必须给代码写注释，就算它看起来不会被别人接手。有时候，研究完一个问题，然后你看着代码觉得那是显而易见的，但是过一两周之后回头再看，你也会摸不着头脑的。