总结一下自己在实践与思考中形成的编码规范

这段时间,公司领导让我做了一些整理工程规范相关的事,趁此机会,我也把以前在规范方面的实践和思考在这里做个整理,阶段性的总结一下,以后还需要不断更新。

正文

/**
 * 原则
 * <ul>
 * <li>一致(一致的缩进量、一致的空行位置、一致的命名,等)</li>
 * <li>直觉(不违背直觉,所见即所想也即所得)</li>
 * <li>语义(有意义的命名、不做牺牲或违背语义的优化,写给人看的代码)</li>
 * </ul>
 * <p>
 * 工程结构
 * <ul>
 * <li>包顶层路径按业务模块切分</li>
 * <li>使用严格的分层模型,请务必遵守,所有代码只出现在它应该出现的地方</li>
 * </ul>
 * <p>
 * 代码编写
 * <ul>
 * <li>代码的语义优先,不要为了优化性能等借口放弃代码的语义</li>
 *
 * <li>禁止使用缩写命名,缩写命名自己都看不懂,更别提给别人看了,使用有意义的英语命名,不要怕名字长,实在喜欢短命名,可以考虑代码混淆器,混淆出来的代码连包都很短</li>
 * <li>禁止在命名中使用错字(以 IDE 没有波浪线提示为准)</li>
 * <li>变量名使用小驼峰命名,类名使用大驼峰命名</li>
 * <li>所有常量定义在 Constants 中,禁止多处定义常量,(但可多处定义枚举)常量类为 final 类(也就是禁止继承)</li>
 * <li>常量(static final)禁止使用小写命名,使用大写 + 下划线方式命名</li>
 * <li>接口禁止使用 I 开头,实现使用 Impl 后缀,接口与实现写在同一包下,不要为实现在建一个层级的包</li>
 * <li>禁用大写方法名</li>
 *
 * <li>写完后请随手格式化(请统一使用 IDE 默认格式化规则)</li>
 * <li>IDE 报黄色警告的地方,看一下是什么原因,尽力消除有警告的代码,这样随手就是优化</li>
 * <li>方法和方法变量和变量之间保持一致数量的空行,方法体内第一行不能为空行(匿名内部类方法除外),类的开始大括号下留一行空行,结束大括号上边不能是空行</li>
 *
 * <li>禁止在方法中保留注释的代码(请将其剪切保存到别出)</li>
 * <li>禁止保留 IDE 生成的 TODO标签,等自动生成项</li>
 * <li>禁止写不必要的注释(不要重复自己),方法、变量看名字就能知道什么语义,就无需注释了,所以命名遵守语义化很重要</li>
 * <li>注释中的 param 和 return 如果感觉不需要写,直接去掉!不要保留空的 param 和 return</li>
 *
 * <li>若类或方法上需要加多个注解,那么在所有需要加多个注解的地方,按照同样顺序排列这些注解,并且按照注解的等级从下向上排列(通用的在下边,特属的在上边)</li>
 *
 * <li>不建议深度优先的包路径,请使用广度优先的包路径,并用前缀或后缀区分包下的类</li>
 * <li>禁止保留无用的 import</li>
 *
 * <li>所有异常不要 catch 直接 throw 到上层,在到达前端之前统一使用 AOP 方式处理</li>
 *
 * <li>maven 中依赖项请安组排列</li>
 * <li>maven 中禁止引入不需要的依赖和插件</li>
 * <li>maven 中明确指定 Java 版本</li>
 * </ul>
 */

原文 

https://since1986.github.io/blog/6e0cf8e6.html

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 总结一下自己在实践与思考中形成的编码规范

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址