从感叹号开始优化你的代码

  eclipse里常常会看到一片的感叹号，既然出现了感叹号就说明代码有不严谨的地方。本人是非常讨厌出现这样的提示的，或许有人会说，那你设置下eclipse，把警告全部去掉了。但这只是掩耳盗铃的做法，没有根本上解决问题。下面看看有哪些问题是经常出现的:

1、多余的import；

2、未引用的定义；

3、没有对可选对象的泛化；

4、实例对象引用静态变量（方法）。

 

好像列举出来最常出现的就这么4种，那为什么我们不能在写代码的时候规范下呢，让自己的代码更漂亮呢。其实代码风格也是可以看出一个人做事的风格，只有存在想着让自己做的事情尽量的完美，你才会有动力去改变你的代码风格，去完善每段代码，从而不断的提高自己。

下面再列举下我经常看到的一些不好习惯（纯属个人意见）

 

一、大片的无用代码注释。有人或许会说，我现在注释掉，或许后面还要用，其实这都是在给自己找借口。扪心问自己一下，你真的还会去用这些代码吗？特别是这些代码本身就是你自己开发的，只有你才是最清楚它的逻辑，你才最有权力去删除这些代码。而别人来看了，只能叹息几下，鬼知道你还要不要用呢。

 

二、大量的if{} else{}。关于这个问题，其实模式的介绍里已经说的很清楚了，如果说是用来最为大业务的方向判断，就需要考虑用设计模式来优化你的代码了；如果这样的逻辑判断随着时间的推延，会出现比较大的变化的，也需要用设计模式来重构了。

 

三、不合理的代码空行。代码空行是很好的提高代码可读性的手段，也是最容易做的。比如逻辑块之间加个空行，return之前加个空行等等。

 

四、注释缺失。这个我想其实每个人都明白，只不过你愿不愿意多花点时间去写。可能有人会说我就写了这么点逻辑，写啥注释啊。确实如果逻辑少的，注释的价值体现的不那么明显，但并不表示它没有。比如你做了一个判断，这个时候你试着站在别人的角度上想想，如果他来看这个代码是否就能马上明白具体的意思呢。或者这么来说吧，如果别人写了这么一段代码，你是不是还要去问下开发的人为什么加这个判断呢。

 

五、重复代码。我一直有这样的观点，要做个“懒人”，“智慧的懒人”，因为“智慧的懒人”才会想着让自己或者别人以后做更少的事。看到了重复的代码出现，或者预见到了这里将是以后共用的逻辑，就自然会想着抽取共用代码，紧接着就会想到用什么模式会更合理的达到这种共用效果。如果说你对模式的理解还不过，也不要紧，抽取共用并不一定要用模式，关键是要有这种思维驱动去做这个事情。

 

六、代码格式化缺失。在一个团队中，每个人都有之际写代码的风格，能力也有好有坏，但代码格式化我觉得是可以统一的。一方面为了大家代码风格更接近；另一方面为了合并的代码冲突几率降到最低。

 

七、硬编码泛滥。存在硬编码的地方，大部分就是可以共用的地方。举个例子：数据库中一个判断enable的字段，存了Y,N来作为是否可用的标志。可以预见到这样的规则不会只有一处，搞个常量或者枚举来替代硬编码是再合适不过了。既提高了共用性，又增加了代码的美观，何乐而不为呢。

 

八、异常处理不合理。异常发生了，大部分情况是需要我们去处理的。checked异常已经在编译期就告诉我们要处理，可以捕获可以继续往外抛，但有一点是要确定的，那就是这个东西你不能扔给你的用户。因为用户是不需要关心这些的，所以返回给用户是相对模糊的提示，如执行异常。而不是把Exception里的信息直接丢给用户，除非是你已知的异常信息。

 

九、日志打印不规范。1、特定业务打在特定日志文件中；2、根据日志作用判断日志级别；3、对debug，info级别加上enabled判断，避免多余的字符串实例消耗。4、message部分需要提现业务的特有信息，尽量不要出现“操作异常”，可以改为“×××业务操作异常”。5、throwable对象不要作为message输出，如logger.error("×××业务异常"+e)。

 

十、缺少对结果（异常）信息的定型。为什么要定型，定型会增加工作量，但同时会提高结果的可控制性，你可以对特定类型做特殊处理。怎么来定型，给结果（异常）对象增加resultCode（exceptionCode）属性，而这个code可以用自定义enum来完成。其中resultCode和exceptionCode可以是用同一个enum，这样就很好的达到exception到result的衔接。