Java编码规范，

Java编码规范，

先借编码规范之名，行吐槽之实，抱歉。

写干净整洁的代码

阅读代码，眼缘很重要。代码是程序员的脸，保持干净整洁。

高效运用注释

有人说注释和代码一样重要，我不太认同。简单优雅的代码比注释更直接易懂，注释会骗人，代码不会，注释不正确比没有注释糟糕很多很多，一大堆无用的注释浪费空间，浪费脑力，不如没有注释。一段关键的算法，一个场景的特殊处理，用简短的注释解释思路，这里注释对于后来的维护人员来说，比代码更加重要。接口的注释是使用接口人员的说明文档，对他们来说也比代码重要。如果一段代码需要你很多很多的注释才能解释清楚，那么请重写那段代码，直到简短注释甚至无需注释。

命名简洁一致

命名规范是代码规范的重要一环。总的原则是遵循惯例，简洁，团队甚至个人命名保持一致。

理解Java几个基本的概念

一些Java的基本概念一定要吃透，否则很容易犯低级错误。

Exception

麻烦统计一下你们项目里面处理异常，简单地e.printStackTrace()个数，少不能说明你们项目代码质量一定很高，但太多了一定意味着你们的代码质量不咋地，如果这些烂代码由很多人提交，那更是悲剧。e.printStackTrace()只是把Exception toString()，然后输出到System.err，开发的时候控制台还能显示一下，生产环境到哪里去找。我觉得简单e.printStackTrace()和try catch之后什么都不干一样恶劣。想看报错信息？借助Log4j或者Logback记日志吧，既能开发的时候控制台看到，也能在生产时记录到文件系统。

• 何时抛出异常
  不正常的场景出现，当前程序决定罢工，并可选择地携带一些错误信息告知调用者，小心，异常。如果你的程序就是最后一环，拜托，别抛了，选择更优雅的方式吧。
• 何时处理异常
  确定你可以处理那样的异常，并且决定catch之后如何继续下面的操作。catch之后记录日志是标配。如果你开发GUI，你就是最后的消费者，必须处理异常。

Transaction

如果你开发的系统要求数据的完整性和准确性，请花些时间好好吃透Transaction。有一个业务Service A，分为两个子Service A1, A2。如果分别调用A1和A2，并放到两个Transaction里面，如果A1执行成功，A2失败并Rollback，请问发生了什么？Service的粒度划分和Transaction的使用非常的重要。

Thread

不懂或者半懂不懂千万别用多线程，要用就去好好的了解一下它。依我的理解，多线程仅用在两个地方，性能提升和响应式(Responsive)的GUI界面。

Access

两个字，要明确。类，构造函数，属性，方法的访问权限要明确。public， protected，package，private，四个级别，了解不难，用好要功力。有的不喜欢明确定义访问级别的朋友会辩解说，我看JDK里面有的属性或者方法就没有申明权限嘛，JDK的开发工程师也懒。哈哈，往后看看，大多会特别的注释说是package级别的，如果package关键字能够用来定义package权限，他们估计早用了，何必还多写那么些冗余的注释。interface里面不用明确申明public，因为默认就是public的，而且只能是public的。程序员太懒惰不好，太勤快了也不好，难当。

寻求更好的解决办法(Better Solution)

项目经理A或业务达人B跑过来，某客户有一个新的需求，请帮忙如此如此改一下系统，如此如此设计。假如你听话马上开始勤奋地敲代码，我觉得90%以上该方案都不是什么好方案。can work与work fine之间有着遥远的距离，改BUG，支持新需求绝对不仅仅是If Else那么简单。套用Linus大神的话，如果A君或者B君比你更了解你的系统，帮你设计由你实现，那么你就没有价值，实现的系统一定很烂，不如A君或者B君直接来实现。大神的徒弟不一定就是大神，传输大都有损耗。找出所谓需求背后的真正动机，结合当前的系统寻求更好的解决方案。何谓更好，各有各的看法，个人觉得，要保持架构风格的统一，要考虑未来类似需求的普适性，要简单准确有效。

结语

以上List处于开放状态，欢迎批评，欢迎加内容。一家之言，还请多包涵。