# [开发规范](https://www.cnblogs.com/xuyangblog/p/11234833.html)
代码规范很重要,可以提高代码的可读性、扩展性、美观性,也能减少Bug出现率,即使出现也可以很快定位问题,解决问题。
**(一)代码命名规范**
1. 驼峰命名:类、结构体首字母大写;方法、参数、变量首字母小写;常量全部大写;
2. 抽象类以Abstract开头;枚举类以Enum结尾;
3. 获取数据以 get 为前缀,例如:getData();获取多条数据以 List 为结尾,例如:getAreaList();插入使用insert为前缀;修改以 update 为前缀;删除以 del 为前缀;其他方法命名尽量体现业务实现
**(二)注释规范**
1. 类注释必须要有,并且每一个类都以实现一个业务操作为基准
2. 方法注释要言简意赅,通俗易懂,不要有太复杂的逻辑
3. 代码注释,尽量在代码块前进行注释,不要放到代码行的后方
4. 接口注释,必须有接口入参及出参说明
**(三)HTML规范**
1. HTML编写,应当先确定页面接口,按照结构,由粗到细,逐步填充内容
2. 非必要,尽量不要使用 position: absolute、float 等浮动布局,如果确实有必要,建议指定父级的relative,不要在全局定位;float之后,要清除掉浮动,减少因浏览器版本导致的布局变动
3. 代码做好缩进,分级编写,不要在一行内写入多层结构
**(四)JS规范**
1. 不建议使用 function xxx(){} 这种方式直接创建方法,建议按照分类,创建方法对象 xxx = { aaa:functoin(){}, ...};例如:加载方法写在Init对象中,验证方法写在Vaile对象中,页面逻辑写在 Handle对象中 等
2. 如果页面JS较多,创建以页面命名的JS,页面引用JS
3. 公共方法中,不使用具体的页面控件对象,如必须使用,尽量减少单个方法内操作的具体对象数量,不使用单个方法做太多逻辑处理,而是通过多个方法共同实现某一个功能
4. 多个公共方法组合实现某个功能时,组合方法不建议作为公共方法,而是用到的地方自己组装
5. 不能方法内部层层嵌套,原则上应该是 业务方法 -> 基础公共方法,每个页面的业务方法都要单独写,哪怕逻辑相同,也要避免使用公用的业务方法
6. 不能再js中进行大量的Html拼接,如有必要,可将html做成部分视图进行js引用处理
**(五)样式规范**
1. 样式也是与HTML相同,先写全局样式,再写模块样式,最后写特殊样式
2. 样式也要层层嵌套,不建议跳过父级模块样式,直接用ID写样式,不好控制;
3. 减少行内样式,如想确定某个样式始终有效,避免被行内样式覆盖,在css中添加 !important
4. 母版页的全局样式,建议单独css文件编写,内容页面样式较少时,直接在页面顶部构建页面单独的样式
**(六)数据库规范**
1. 表命名以 t 为前缀;视图以 v 为前缀;存储过程以 p 为前缀;触发器以 tri 为前缀;
2. 表命名使用英文,全部小写,单词之间以下划线“\_”分隔
3. 表名和字段名尽量简短
4. 大长度字段,建议单独表存储,通过id管理
5. 字段过多时,做表横向切割,可以按照字段业务来划分,例如 订单提交信息;订单流转控制信息;订单业务信息等;
6. 索引等信息避免大字段;
7. 写修改或者删除脚本时,先写条件,在写要修改或者删除的语句;修改尽量先查找出来id,通过唯一id进行修改
8. count() 和 count(xxx) 语句查询结果是不一致的,前者是不去null,后者是去除null之后的数据
9. 当表较多时,建议按照业务,使用不同的数据库用户名(架构名),既方便查找,也方便进行管理
**(七)异常规范**
1. 要区分稳定代码和非稳定代码;不能使用try catch包裹所有代码进行异常捕捉;
2. 不能try catch中嵌套try catch,只在非稳定代码中加try catch
3. finally中不能使用return;
4. 捕捉异常之后,若吞没该异常,尽量做好日志记录
5. 若继续抛出的异常将会脱离框架控制范围,必须做result套接;例如接口,不能直接将异常抛给客户或业务端,导致外部资源崩溃;
6. 对内业务,建议处理异常并抛出异常提示,对外代码,建议以代码Code标识异常类型
7. 避免一个异常,多处重复记录
**(八)接口规范**
1. 接口返回必须有result包裹,不能直接返回data数据
2. 接口尽量避免返回null,建议处理成空对象返回;如有需要返回null,需要在接口中注明,并提示接口调用方对返回值做校验
3. 接口架构:可以使用同一个对外接口,根据枚举类型的不同Code进行,使用IOC分别映射到不同的接口实现类中,好处是可以很方便的对接口请求做控制和验证,代码结构也比较整洁有序,后续新增或修改接口时,只需要改动相应的业务即可,无需考虑验证问题
- 视觉规范
- 色彩
- 文字
- 偏移
- 图标
- 列表组件
- 表单组件
- 详情组件
- 其他组件
- 研发规范
- 编码规范
- 函数式编程
- 纯函数
- 柯里化
- 函数组合
- 函子
- 面向对象编程
- 设计原则
- 单一职责原则
- 里氏替换原则
- 依赖倒置原则
- 接口隔离原则
- 开闭原则
- 迪米特原则
- 组合复用原则
- 设计模式
- 创建型模式
- 工厂模式
- 简单工厂
- 工厂方法
- 抽象工厂
- 单例模式
- 建造者模式
- 原型模式
- 结构型模式
- 适配器模式
- 桥接模式
- 过滤器模式
- 组合模式
- 装饰器模式
- 外观模式
- 享元模式
- 代理模式
- 行为型模式
- 责任链模式
- 命令模式
- 解释器模式
- 迭代器模式
- 中介者模式
- 备忘录模式
- 观察者模式
- 状态模式
- 策略模式
- 模板模式
- 访问者模式
- 组件设计规范
- 组件文档编写规范
- 版本管理规范