一、命名这事儿得走心

别再用a、b、c这种变量名糊弄事了。好的命名应该让同事三秒内看懂这变量是干嘛的。比如就比强得多，而直接说明了这是订单创建时间。遇到布尔类型的变量，记得用is、has、can这些前缀，比如、，读起来就跟说人话一样。

二、代码结构要清爽

最近在代码评审时看到个三百行的方法，里面塞了五层嵌套的ifelse，看着就跟俄罗斯套娃似的。建议单个方法别超过50行，超过80行就得考虑拆分了。还有那个，千万别图省事用通配符，谁知道会导进来什么奇怪的东西？另外静态导入要慎用，容易让读代码的人分不清方法来源。

三、异常处理不是摆设

最烦看到代码里满屏的，这种抓了异常又不处理的写法简直就是埋雷。该抛出的异常就得抛出，别在底层悄咪咪地吞掉。自定义业务异常要比直接抛RuntimeException强，至少能让人明确知道出了什么类型的错误。资源关闭记得放在finally块里，或者直接用try-with-resources语法，这可是Java7就有的好东西。

四、集合使用要讲究

见过最离谱的是有人用来做缓存，问他为什么，说线程安全。其实在大部分场景下，的性能要好得多。要是真需要线程安全，比香多了。还有要注意返回的列表不支持增删操作，不小心掉进这个坑的程序员不在少数。

五、字符串拼接有门道

循环体内用拼接字符串的，建议去面壁思过。在单线程环境下性能最优，因为加了同步锁，性能会差些。不过现在Java编译器对字符串优化做得不错，简单的拼接会自动转成，但在循环里还是得自己控制。

六、日志打印要规范

调试的时候最怕遇到两种人：一种是到处打的，另一种是日志打得跟写小说似的。建议用SLF4J配合Logback，按需调整日志级别。ERROR级别用来记录需要人工干预的错误，WARN级别关注异常情况，INFO级别记录关键业务流程，DEBUG级别留给开发调试用。打印日志时记得判断日志级别，避免不必要的字符串拼接开销。

七、线程安全要警惕

SimpleDateFormat不是线程安全的，这点坑过不少人。推荐用ThreadLocal包装或者改用Java8的DateTimeFormatter。静态变量也要特别注意，如果会被多线程修改，一定要做好同步控制。使用线程池时记得给线程起个有意义的名字，出问题时查堆栈跟踪能省不少时间。

八、数据库操作要优化

MyBatis里别动不动就select *，需要什么字段就查什么。Entity类里尽量用包装类型，因为int的默认值0容易和数据库里的null产生歧义。批量操作记得用batch模式，循环里单条insert的性能简直没法看。

九、设计模式别滥用

见过为了用设计模式而用设计模式的，简单的业务逻辑硬是套上七八个设计模式，美其名曰“架构优雅”。实际上如果只是增加一个if判断就要改三个文件，那这设计肯定有问题。记住，合适的才是最好的。

说到底，编码规范不是束缚创造的枷锁，而是避免踩坑的经验总结。养成良好的编码习惯，既是对自己负责，也是对团队负责。毕竟谁都不想凌晨三点还被报警短信叫起来查bug，对吧？把这些规范融入到日常开发中，时间长了就会发现，代码质量上去了，加班时间下来了，这才是双赢。