转载

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

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

正文

/**
 * 原则
 * <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

正文到此结束