前端开发命名规范.docx

前端开发工作规范
为提高团队协作效率，便于后台人员添加功能及前端后期优化维护，输出高质量的文档，特制订此文档。本规范文档一经确认，前端开发人员必须按本文档规范进行前台页面开发。
【写在规则前面的话】
项目的可维护性第一。你不是一个人在做事，项目的维护和二次开发可能是直接的或间接的团队合作。好的可维护性，从四个方面下手：
1）代码的松耦合，高度模块化，将页面内的元素视为一个个模块，相互独立，尽量避免耦合过高的代码，从html,css,js三个层面都要考虑模块化。
2）良好的注释。
3）注意代码的弹性，在性能和弹性的选择上，一般情况下以弹性为优先考虑条件，在保证弹性的基础上，适当优化性能。
4）严格按照规范编写代码。

【命名规则】
为避免命名冲突，命名规则如下：
1）公共组件因为高度重用，命名从简，不要加前缀；
2）各栏目的相应代码，需加前缀，前缀为WD姓名拼音的首字母，例如：杰夫前缀为“jf_”，分隔符为下划线“_”，例如：“jf_imgList”;
3）模块组件化，组件中的class或id名采用骆驼命名法和下划线相结合的方式，单词之间的分隔靠大写字母分开，从属关系靠下划线分隔。例如：
html:<ulclass=”textList”><liclass=”textList_firstItem”>1)XXXXXXXXXXXXXX</li><li>2)XXXXXXXXXXXXXX</li><li>3)XXXXXXXXXXXXXX</li></u1>css:.textList{}.text_listX{}.textList_firstItem{}.textListFirstItemX{}
4）命名清晰，不怕命名长，怕命名容易冲突，长命名可以保证不会产生冲突，所以css选择时可以尽量不使用子选择符，也能确保css优先级权重足够低，方便扩展时的覆盖操作：.textList_firstItem{}.textList.firstItem{}
5)命名要有意义，不要使用没有意义的命名。用英语命名，不要用拼音。

【分工安排】
1)分工原则为公共组件（包括common.css和public.JS）一人维护，各栏目其他人负责，每个栏目正常情况下一人负责，要详细写明注释，如果多人合作，维护的人员注意添加注释信息，具体注释细则，详见注释规则；
2)VD设计完设计图后，先和交互设计师沟通，确定设计可行，然后先将设计图给公共组件维护者，看设计图是否需要提取公共组件，然后再提交给相应栏目的WD。如果有公共组件要提取，公共组件维护者需对栏目WD说明。
3)如果确定没有公共组件需提取，交互设计师直接和各栏目的WD交流，对照着VD的设计图进行说明，WD完成需求；
4)WD在制作页面的时候，需先去common文件中查询是否已经存在设计图中的组件，如果有，直接调用；没有，则在app.css和app.JS中添加相应的代码。
5)WD在制作过程中，发现有高度重用的模块，却未被加入到公共组件中，需向公共组件维护人进行说明，然后工作组件维护人决定是否添加该组件。如果确定添加，则向WD们说明添加了新组件，让WD们检查之前是否添加了类似组件，统一更新成新组件的用法，删除之前自定义的css和js。虽然麻烦，但始终把可维护性放在首位。
6)公共组件维护者的公共组件说明文档，需图片和说明文字配套，方便阅读。

【注释规则】
1.公共组件维护者和各栏目WD都需要在文件头部加上注释说明：/***文件用途说明*作者姓名、联系方式（旺旺）*制作日期**/
2.大的模块注释方法：//================//代码用途//================
3.小的注释；//代码说明注释单独一行，不要在代码后的同一行内加注释。
例如：//姓名varname=“abc”;Vvarname=”abc”;//姓名X
4.维护人员的注释方法：尽量根据注释说明，找到代码的原作者，让原作者进行维护，原作者进行维护可以无需添加额外说明，直接进行修改。如果因为特殊原因，无法让原作者进行维护，需添加额外说明进行注释。说明文字为：“/*changebyxxx)原代码如下：<{源代码}>.新代码如下:*/新代码：如：varname=“abc”;这段代码，要将name由“abc”变成“123”，原作者可直接改varname=”123”;非原作者修改，需改成：/*(changeby杰夫)原代码如下：<{varname=“abc”;}>新代码如下：*/varname=”123”;
修改时添加的注释，在项目通过测试之后，上线前，可以优化掉。

【js规范】
1)底层JS库采用YUI2.6.0；
2)统一头部中只载入YUIload组件，其他组件都通过loader对象加载；
3)js尽量避免使用全局变量，复杂应用写成组件