开发规范

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

总结：

　　每次看到之前写的代码，都感受很渣，这是本身能写出来的代码？而后或者默默优化一下，或者直接忽视，等到问题爆发在进行打补丁式的查找修改。

　　写这篇文章的目的也是对之前编程的一个回顾，即便到目前为止，上述的不少规范也没有作到，加以自勉吧！