开发规范

  代码规范很重要,可以提高代码的可读性、扩展性、美观性,也能减少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分别映射到不同的接口实现类中,好处是可以很方便的对接口请求做控制和验证,代码结构也比较整洁有序,后续新增或修改接口时,只需要改动相应的业务即可,无需考虑验证问题

总结:

  每次看到以前写的代码,都感觉很渣,这是自己能写出来的代码?然后或者默默优化一下,或者直接忽视,等到问题爆发在进行打补丁式的查找修改。

  写这篇文章的目的也是对以前编程的一个回顾,即使到目前为止,上述的很多规范也没有做到,加以自勉吧!

原文地址:https://www.cnblogs.com/xuyangblog/p/11234833.html