代码规范这东西网上很容易百度到一堆,除了天下文章一大抄的问题,另外,多数只给了结果,原因没有充分说明,或者非常的纠结于大写小写,一个函数可以写几行的细节。感觉有点容易让新人误入歧途。
于是锅叔打算根据自己的经验分析下这些规范产生的原因,帮助新人深入理解为什么这么规定,知其然并知其所以然。
工作中如果你没怎么接手过其他同学的代码,那肯定会比接手过离职同学的代码,经常帮其他同学排查Bug的“大牛”们对 代码可维护性 的理解,要差上一个数量级。
如果你没怎么参与过一个持续存在3-5年以上,需求变更频繁的系统模块的迭代开发,你也不容易理解, 代码重构 对于一个稍作修改,就Bug此起彼伏的模块质量改善的重要意义。
对软件的迭代效率和质量负责任的人通常就是Team Leader,PM,这类第一责任人,他们深思熟虑一番后,得出一个重要结论,上面这些难于交接,修改困难,Bug横行的坑,很大程度上都跟代码写的不 规范 有关,因此就编写了 代码规范。
程序员的本质也是个手艺人,与大部分其他行业的施工规范的作用相似,主要是作用是
1. 避免造成施工缺陷,提供施工质量。
2. 方便同行交流,以便后期维护。
举个例子,锅叔家中近来正好在装修,因为不是从毛坯重头装修的,这样一些水电的走线情况就不是很清楚了,是装修前已经施工完毕的。理论上开关插座线路是可以随意的铺设的,只要联通就可以,可以一会儿排成一字,一会儿排成人字。这时比如你需要在墙上挂一副画或者镜子,需要在墙上打孔固定,那这个孔会不会打穿墙内的水电线就非常随缘了。安装师傅只能根据布线规范和经验判断,一般的电线布线在墙面是横平竖直的,不会斜着来,或者转圈圈,水管一般走天或者走地。你也就只能祈求之前施工的水电师傅是遵循这个规范来的,如果他走线很有个性导致你打坏了线路要重新维修,你一定会在心里问候他的。
实践中代码规范的内容很多团队应该是“借鉴”来的。锅叔其实建议,借鉴了之后,还要重视后期的调整,补充。每个团队的技术栈,项目特点会有不同,在编程上的关注点也会对应不同。代码评审不应简单的以规范为准,而应该以提高可维护为目的。评审中发现而未在代码规范中包含的内容,要及时增补。同时评审时还要注意传达规范的目的,而不仅是让大家机械遵守。
下面是一些锅叔觉得比较常见重要的,做一下简单解释说明,排名不分先后 。
可读性,自己体会
if(deviceState == 1){
doSomeThing();
}
//对比
if(deviceState == DEVICE_STATE_ON){
doSomeThing();
}
合理分层,自行体会
function A(){
买菜();
备菜();
炒菜();
}
function B(){
……
下楼;
打开车门;
按下点火开关;
打左转向灯;
鸣笛;
开出车位;
如果遇到隔壁老王就打个招呼;
出小区右转;
第二个十字路口左转;
进菜市场左转第一个摊位,买两斤黄瓜;
拿上黄瓜,步行回车上;
扫码交车费;
…………
}
function A(){
if(a == 1){
B();
}else{
C();
}
}
//VS
function 送礼物(){
if(用户性别 == 男){
送茅台();
}else{
送古驰();
}
}
懒得举例了,自行体会
送礼物 方法,做了他命名之外的事,很容易被调用的人错误使用
function 收礼不办事举报(){
送礼物();
if(不办事 并且 不是我干爹){
举报他();
}
}
//VS
function 送礼物(){
if(用户性别 == 男){
送茅台();
}else{
送古驰();
}
if(不办事){
举报他();
}
}
典型的如没有数据和发生错误,无法返回数据是不同情况,要加以区别。
错误要写日志, 不至于死无对证。。-_-||
让用户知道,现在正在处理,不是系统故障了。
当数据记录上亿时,一次全部取出,放入内存,可能会使服务器宕机……
作者:锅叔
原文链接:https://www.cnblogs.com/uncleguo/p/16143561.html
目前我们现在用的前后端分离模式属于第一阶段,下一阶段可以在前端工程化方面,对技术框架的选择、前端模块化重用方面,可多做考量。也就是要迎来“==前端为主的 MV* 时代==”。
当您必须使用匿名函数,请使用箭头函数表示法,它创建了一个在 this 上下文中执行的函数的版本,这通常是你想要的,而且这样的写法更为简洁。如果你有一个相当复杂的函数,你或许可以把逻辑部分转移到一个声明函数上。
standard是一个开源的JS代码规范库,制定了所谓standard(标准)的JS代码规范,配合编辑器插件可以实时检查代码规范以及语法错误,通过执行命令检查代码规范以及语法错误,自动修复(可以直接修复的)不合规范的代码,使其符合规范
对于一个多人团队来说,制定一个统一的规范是必要的,因为个性化的东西无法产生良好的聚合效果,规范化可以提高编码工作效率,使代码保持统一的风格,以便于代码整合和后期维护。
为了编写可维护的代码,我们把很多函数分组,分别放到不同的文件里,这样,每个文件包含的代码就相对较少,很多编程语言都采用这种组织代码的方式。在Node环境中,一个.js文件就称之为一个模块(module)
引号的使用,单引号优先(如果不是引号嵌套,不要使用双引号)、空格的使用问题:(关键字后 符号后 排版 函数 赋值符号= )等、不写没有使用过的变量,如果定义了一个变量,后来一直没有参与过运算,那么不应该定义这个变量...
嵌套的节点应该缩进;在属性上,使用双引号,不要使用单引号;属性名全小写,用中划线做分隔符;不要在自动闭合标签结尾处使用斜线(HTML5 规范 指出他们是可选的);不要忽略可选的关闭标签;
CommonJS规范规定,每个模块内部,module变量代表当前模块。这个变量是一个对象,它的exports属性(即module.exports)是对外的接口。加载某个模块,其实是加载该模块的module.exports属性。module.exports属性表示当前模块对外输出的接口
W3C通过设立领域(Domains)和标准计划(Activities)来组织W3C的标准活动,围绕每个标准计划,会设立相关的W3C工作组织(包括工作组、社区组、商务组等)。W3C会根据产业界的标准需求调整Domains和Activity的设置及相关的工作组设置。
不要使用 @import 与 <link> 标签相比,@import 指令要慢很多,不光增加了额外的请求次数,还会导致不可预料的问题。CSS有些属性是可以缩写的,比如padding,margin,font等等,这样精简代码同时又能提高用户的阅读体验。
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!