• 变量：小驼峰 (例：userName)
  • 常量：全部大写，单词间以下划线连接 (例：NAV_MENU)
  • 私有变量：下划线开头 (例：_userName)
  • 类名：大驼峰 (例：UserName)
  • 枚举：大驼峰
  • 组件指令选择器：小写短横线连接 (例：app-demo)
  • 管道：名小驼峰，类名大驼峰

  • 可观察对象：$开头 (例：$timer)

    文件结构及文件名

  • 小写短横线连接（例：hr-list）使用点来分隔描述性名字和类型，模式为feature.type.ts 【 如.service.ts、.component.ts、.pipe.ts、.module.ts、.directive.ts】或者其他少量的自定义类型

  • 单个组件所有文件放同一文件夹下，不同类型（指令、管道、服务）以文件夹分开

    最佳实践，推荐写法

  • 一个函数行数不要超过75行（单一职责原则），一个方法应该作为整体去完成一件事情，如果其中有多个操作，那么我们可以抽取这些方法，形成独立的函数，使得他们独自负责各自职责，再去调用他们，因为长方法难以阅读、理解以及维护。他们容易产生bug，因为改变其中一部分很可能影响方法内的其他逻辑。这也使得代码重构更加难以进行。

  • 一个文件代码行数不要超过400行，单组件文件非常容易阅读、维护，并能防止在版本控制系统里与团队冲突，并且可以让代码更加可复用、更容易阅读，减少出错的可能性
  • 以.state.service.ts结尾的文件来定义数据层（用来做数据请求隔离，以及非交互的业务比如增删改查），一般一个文件对应一个对象实体（若业务逻辑实在复杂也可拆分为几个文件并放置在同一文件夹下）
  • DRY原则(Don’t Repeat Yourself)
  • 一个小模块独立一个路由模块，且懒加载（注意要避免直接导入惰性加载的模块）
  • 封装公用组件注意解耦
  • 将组件的表现层逻辑放到组件类而非模板里，可以增强测试性、维护性和重复使用性。
  • 尽量避免使用 any 类型
  • 避免使用无意义的变量名
  • 避免使用无意义的类型值来赋值或比较（使用枚举值代替）
  • 避免对于据有某些特定值的string类型定义为 string（使用string的枚举类型代替， 如 ‘apple’|’banana’ 替代 string）

  • 尽量避免直接操作dom元素、

    后台

  • 字段统一，避免前端重复取值

  • 排序页数避免1，2，3数字
  • 不使用魔法值