前端开发确保代码清洁的一些建议

写出看起来清晰的代码,不仅有利于后期的维护扩展,也方便他人的阅读以及参与,能够充分发挥多人协作的力量。再一个,往往简洁优雅的代码也是最高效的。写出一份简洁清晰的代码,一般有如下几个因素决定:

前端开发确保代码清洁的一些建议

越是约束简单、语法灵活的语言有一个特点:上手容易,精通难,这个特性真的是一把双刃剑,而前端开发的灵魂语言JS就是属于此种。

1.代码的细节处理

众多开发人员,每个人的大脑都是不一样的,那么写出来的代码也是不一样的,无论再怎么规范,再好的开发工具辅助,每个人的代码始终是个性的,也正是因为这样,每个人的才会创造出不同的东西。

但是别人良好的思路是可以借鉴的,落实到代码层面,就是多阅读别人的代码,为什么人家的代码看起来如此清晰?很复杂的事情居然被有条不紊的搞定,经常汲取好的思路,纠正自己,时间长了,就会是一笔财富。

a) 命名空间

除非是系统提供的原生对象,或者是一些非常牛叉的框架可以不需要命名空间之外,尤其在项目里面,我们封装的对象都需要放在一个命名空间下面,否则久而久之,势必对扩展带来阻碍,概念混淆、冲突问题会接踵而至。
而命名空间的路径也需要特别注意,里面不要掺杂一些英文单词之外的字符,比如下划线,横杠之类的,而且最好是单个词。

b) 对象的命名

对象的名称可以是单个或者多个单词的组合,比如 piao.detail.List 或者 piao.detail.SightMap,而且最好不要超过2个单词,3个单词是勉强可以接受的,再多可读性就会明显降低了。作为对象名称首字母一定要大写,不然会和普通变量混淆。

c) 私有属性的命名

目前私有属性常见的有三种命名方式,比如this.index、this.index_、this._index,这个是仁者见仁智者见智的,如果要和普通变量加以区分的话,个人倾向于第三种,因为私有属性多了,下划线放在开头的话,会更加的醒目一致,不会受限于私有属性名称的长短,而导致“_”位置的飘移。

d) 及时的return、continue、break

函数、循环、switch的内部,最让人头疼的莫过于N多层if else的嵌套,说不客气点,超过3层的if else代码简直是不堪入目。不要把自己以及代码阅读者的智商想象的太高,再复杂的逻辑,只要动脑筋一定可以不用那么嵌套的。

而及时的让自己的代码return出函数,就可以大大降低代码嵌套的层数。及时的continue和退出循环也是同样的道理,下面大家看一段代码:

获取默认联系地址

function getPreferredAddress(person) { if (!person || !person.contacts) { return; } var preferredAddress = null; for (var i = 0; ivar contact = person.contacts[i]; if (!contact || !contact.preferred) { continue; } preferredAddress = contact.address; break; } return preferredAddress; }

大家可以想象一下,虽然上面代码逻辑并不复杂,但如果换成用if把里面的代码都包起来的思路去写,是什么样子。

e) 降低循环嵌套的次数

for循环本身就比较复杂,一般嵌套两层还可以接受,一旦比较多,index容易冲突,复杂度也会急剧提升,对于确实复杂的情况,可以考虑把里面的拆分到函数里面来作为缓解,一般不是特别的算法,是不会嵌套那么多层,这个时候往往需要静下来想想,把思路再理一理。

f) No注释?

除了一些特殊的算法和逻辑需要注释之外,90%的情况代码是无需注释的(比如对getContact添加注释获取联系人,这。。。),深信良好的代码是自注释的,而开发人员也不要试图通过注释来降低对自己代码的要求。而现在好多开发人员在面对无用代码的时候,采用的是注释,而不是移除,导致代码大篇幅的被注释,居然还堂而皇之的给别人说:防止以后用到。

如果自己开发的是框架,类库之类的,也是通过文档的描述来告知别人使用的方法。

g) 函数调用冗长

看到过这样的一句代码:window.context.images.split("[")[1].split("]")[0].split(","); 不知道这句如何能够保证不出异常?这样的代码不仅不清晰,而且还不安全,完全看不懂要做什么,获取什么东西。

h) 适当利用Map

有时候为了根据一个值取到另一个值去写一堆if else或者switch,并不是一个好的方法,利用map,会让代码的长度更短,效率也更高。

I) 方法的命名?

关于方法的命名,尽量遵循简短清晰的原则,但也不是绝对的。如下这个情况哪个更好呢?

sns.Contact.getContactById 和 sns.Contact.getById 诸如此类的情况太多了,往往开发人员会认为方法里面不包含对象信息,无法描述其准确意图,其实有对象作为前提,这个顾虑是不需要的。

除了上面这些,还有if、for后面单语句是否需要花括号,以及左花括号是否需要另起一行等等,大家有时间的话,这些细节都可以考虑一些,做做对比,看哪种更好一些。

2.开发工具的选型

前端开发工具目前大多还是以文本编辑器为主,像eclipse、VS这样重量级的还是无法应用到前端。说到开发工具,有一个问题比较有意思,大家可以思考一下:如果过度依赖于编辑器的语法提示,很多属性可能都记不住,那么这个到底有没有关系?也就是说有个问题,作为前端开发人员,到底有没有必要把自己炼化成一部活词典?

3.框架、类库的利用

不重复造轮子,利用别人做好的成果来提升自己的效率是至关主要的。而且不光提升效率,也会大大降低代码量,让自己的代码更加专注。

如果把前端开发按照使用端分个类的话,大概有三种:

a) 企业内网使用,特点是访问量小,并发要求低。

这种是可以选择框架的,比如ExtJS等稍微重量级的,当然如果仅仅选择类库就可以搞定更好。

b) 外网用户访问,特点是高PV,多并发。

这种选择框架就需要谨慎了,如果无太复杂的需求,选择jQuery,足矣,剩下的一些可以自己包装,或者选择一些轻量级的jQuery插件。

c) 手机、pad移动端,特点是网速较低

在移动端,要求更高了,压缩过的jQuery可能都显得略大,这个时候还有一些更好的选择,如果需求简单的话,可以尝试用原生代码自己开发或者使用zepto JS。

4.良好的代码review以及重构习惯

就算大师级别的,也很难一下子就写出高科维护、优雅而简洁的代码,一般好的代码都是经过不断的无数次的调整,甚至推翻重来。尤其面对较大的项目压力,可能会说,天天都有事情做,哪有时间做这些?

我们知道,这只是借口而已,真正的原因是内心抵触做这些事情,我们可以通过让自己的一部分工作自动化或者半自动化来节省时间,而且让我们的代码更好,本身就是节省时间的有效手段,稍微长远来讲。

而且很多优化重构能在上线之前完成是最好不过的,这个就要看具体的项目情况和时机了。

保持代码清洁从代码诞生之初到以后,都是需要持续关注的问题,每个人的理解和要求也都不一样,本文只是抛砖引玉,希望大家可以发表自己的看法,提出更多行之有效的方法出来,就再好不过了。

相关阅读