Skip to content

Latest commit

 

History

History
162 lines (126 loc) · 6.72 KB

JavaScript开发规范.md

File metadata and controls

162 lines (126 loc) · 6.72 KB
Raw

编程规范

命名风格

1、代码中的命名严禁使用拼音与英文混合的方式，更不允许直接使用中文的方式。

  • 正例：Shanghai 等国际通用的名称，可视同英文。
  • 反例：getPingfenByName() [评分]

2、文件夹命名，类文件父目录UpperCamelCase，其余小写，中划线链接。

3、文件命名，类、组件、类型、枚举、接口文件UpperCamelCase，其余lowerCamelCase风格。

4、方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格，必须遵从驼峰形式。

5、类、组件、类型、枚举、接口使用UpperCamelCase风格，必须遵从驼峰形式。

6、常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。

7、抽象类命名使用Abstract或Base开头；异常类命名使用Exception结尾；测试类命名以它要测试的类的名称开始，以Test结尾。

8、杜绝完全不规范的缩写，避免望文不知义。

  • 反例：AbstractClass“缩写”命名成AbsClass；condition“缩写”命名成 condi，随意缩写降低了代码的可阅读性。

9、任何自定义编程元素在命名时，使用尽量完整的单词组合来表达其意。

  • 反例：变量 let a;。

10、如果模块、接口、类、方法使用了设计模式，在命名时体现出具体模式。

  • 正例：function LoginProxy; class ResourceObserver;

11、枚举类名建议带上Enum后缀，枚举成员名称需要全大写，单词间用下划线隔开。

  • 说明：枚举其实就是特殊的常量类，且构造方法被默认强制是私有。
  • 正例：枚举名字为ProcessStatusEnum的成员名称：SUCCESS / UNKOWN_REASON

12、方法命名规约：

  • 获取单个对象的方法用get做前缀。
  • 获取多个对象的方法用list做前缀。
  • 获取统计值的方法用count做前缀。
  • 插入的方法用save/insert做前缀。
  • 删除的方法用remove/delete做前缀。
  • 修改的方法用update做前缀。

13、避免在不同代码块的局部变量之间采用完全相同的命名，使可读性降低。

  • 反例
function getName(){
  if(condition1){
    let name = '';
  }
  if(condition2){
    let name = ''
  }
}

14、避免使用var，以及使用未定义的变量。

  • 反例
function test(){
  a = 'test';
  return a;
}

15、禁止隐式声明，禁止声明或赋值的变量没有使用。

常量定义

1、不允许任何未经预先定义的常量直接出现在代码中。

  • 反例
if(type==='1'){
}

2、不要使用一个常量类维护所有常量，要按常量功能进行归类，分开维护。

  • 说明：大而全的常量类，杂乱无章，使用查找功能才能定位到修改的常量，不利于理解和维护。
  • 正例：接口状态码相关常量放在 APIStatusConsts 下；系统配置相关常量放在 ConfigConsts 下等
控制语句

1、在一个 switch 块内，每个 case 要么通过 continue/break/return 等来终止，要么注释说明程序将继续执行到哪一个 case 为止；在一个 switch 块内，都必须包含一个default 语句并且放在最后，即使它什么代码也没有。

  • 说明：注意 break 是退出 switch 语句块，而 return 是退出方法体。

2、在 if/else/for/while/do 语句中必须使用大括号。

  • 说明：即使只有一行代码，避免采用单行的编码方式：if (condition) statements;

3、表达异常的分支时，少用 if-else 方式，这种方式可以改写成：

if (condition) {
 ...
 return obj;
}
// 接着写 else 的业务逻辑代码;
  • 说明：如果非使用 if()...else if()...else...方式表达逻辑，避免后续代码维护困难，请勿超过 3 层。
  • 正例：超过 3 层的 if-else 的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现，其中卫语句即代码逻辑先考虑失败、异常、中断、退出等直接返回的情况，以方法多个出口的方式，解决代码中判断分支嵌套的问题。

4、除常用方法（如 getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。

  • 说明：很多 if 语句内的逻辑表达式相当复杂，与、或、取反混合运算，甚至各种方法调用，可读性较差。
  • 正例：
const existed = (xxx != null) && (...) || (...) && foo();
if (existed) {
 ...
}
  • 反例：
if ((xxx != null) && (...) || (...) && foo()) {
 ...
}

5、不要在其它表达式（尤其是条件表达式）中，插入赋值语句。

  • 反例：
const a = (b=1);
(c=1)?foo():boo();

单元测试

1、好的单元测试必须遵守自动化、独立性、可重复的原则。

2、单元测试应该是全自动执行的。输出结果不需要人工检查。单元测试中不准使用console.log来进行人工验证，必须使用expect来验证。

3、保持单元测试的独立性。单元测试用例之间不能互相调用，也不能依赖执行的先后次序。

4、单元测试是可以重复执行的，不能受到外界环境的影响。

5、对于单元测试，要保证测试粒度足够小，有助于精确定位问题。单测粒度至多是组件、类级别，一般是方法级别。

6、代码的修改影响了原有单元测试，及时修正。

7、编写单元测试代码遵守 BCDE 原则，以保证被测试模块的交付质量。

  • B：Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
  • C：Correct，正确的输入，并得到预期的结果。
  • D：Design，与设计文档相结合，来编写单元测试。
  • E：Error，强制错误信息输入（如：非法数据、异常流程、业务允许外等），并得到预期的结果。

8、if while for 等语句，真假值都需要测试

9、在项目提测前完成单元测试，不建议项目发布后补充单元测试用例。

安全规约

1、禁止渲染未经安全过滤或未正确转义的数据

2、禁止执行未经安全过滤或未正确转义的脚本

3、长列表、多数据等，需要懒加载，不能一次渲染太多节点

4、机密数据需要加水印

ECMAScript

1、禁止使用废弃的api

2、尽量不要使用eval、with

3、禁止使用有歧义的js

4、禁止使用js的“奇淫艺巧”

5、使用定时器，必须要清除，全局的除外

6、使用class、extends等语法实现OOP

7、使用===，禁止使用==

8、拥抱变化，使用通过标准的最新api替代旧的

ps

因为团队用TypeScript开发，所以包括TypeScript的规范

参考