多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
# [开发规范](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分别映射到不同的接口实现类中,好处是可以很方便的对接口请求做控制和验证,代码结构也比较整洁有序,后续新增或修改接口时,只需要改动相应的业务即可,无需考虑验证问题