总结关于【代码中的坏味道】

代码检查工具方法建议是不要超过80行，这只是一个参考标准而已。这样做的目的是：如果超过80行，阅读起来会相对费劲。也见过上千行的方法，这种超级方法不管注释写得再好、代码命名再规范，对于阅读的人来说，都是一种痛苦。

解决办法：首先，看能不能把业务拆分一下。分成几步：先干什么、再干什么、最后干什么。其次，给一个对象set参数时候，看能不能封装成一个方法，因为这部分代码就仅是set参数而已，跟业务关系不大的。比如：第一步，校验方法入参；第二步，业务处理；第三步，组装返回参数。把一个大方法拆分成多个小方法。

在百分之九十九的场景中，要把方法变小，将方法中适合集中的部分，提炼出来形成一个新方法。

02 代码重复

使用IDEA的小伙伴应该都知道，如果你的代码存在重复，那么重复的代码颜色会变的，把鼠标放上去就会提示你存在多个一毛一样的代码，建议你使用同一块代码。

解决办法：把共同代码块提取出来。通常做法是提取成一个方法，然后有使用到的地方，调用这个方法即可。

03 代码起名

一个项目开发出来，如果不review代码，不做规范，后期很容易出现“同一个业务名出现各种各样的英文名”的情况。比如说：账户通常翻译成account，但是有的人写成acct，有的人写成amount（这个我是见过的）。这也是因为代码中需要起名字的地方太多了：类名，方法名，常量名，变量名……

解决办法：最好是开发的时候搞一个常见命名单词库，要什么单词先去里面查一下，是否已经存在了。对于不存在的，大家一起商量着怎么命名，确定了后将其写到单词库。久而久之，大家就形成习惯了，后面有新人来接手老代码的时候，对于有歧义的单词就可以直接查看单词库。

04 神奇的魔法数字

项目开发中经常会遇到if(age==25)....。请问这个25代表什么？还有setStatus(0)这是什么意思？如果代码没有做review，大约99%的代码里都会出现这样类似的魔法数字。我之前接触过一段老代码，写着：

if(amount==200){
    ...
}else{
    ...
}

当我去问前辈们的时候，人家回我一句就是：if里的代码从来就没走过，一直是走else里的代码，记住就可以了。

解决办法：1）搞常量类，把一些常量类放进去，统一管理并写好注释；2）搞成枚举类，把部分相关联的魔法数字写到枚举中统一管理并写好注释。

05 过多的或者无注释

网上流行一句话：请保证你的代码有效期更长一点。如果关键地方不写注释，即使是自己写的代码，很多时候回溯也会一时半会想不起来那到底是个什么东东。交给人来阅读并维护你的代码，对方心情可想而知……

但是也不是说写了注释，就没问题了。有的人爱学JDK源码、其他框架源码，学到了人家一个类里写了大量的注释，结果咋项目中他也把那种思想用起来了。本来是好事，但是由于注释过多，加上汉语博大精深。看完对方的注释后，会感觉云里雾里，不知道在说什么……

解决办法：注释尽量简单明了，浅显易懂。实在无法描述的地方，你可以使用demo案例来说明，具体可以参考JDK、Spring等框架中大神们的注释。

06格式化代码

为什么要格式化呢？我们在开发的时候，可能多个人对同一个文件进行修改，比如A写一个类，但是代码没有格式化，然后把代码提交上去，这时候B把你代码拉下来改动一部分，然后格式化了代码，但是B还没有提交，然后A也再次把本地代码改了一部分，B把代码提交了，B这时候是无法提交代码的，只能先更新代码。那么问题来了，B已经把代码格式化了，A得合并代码，A合并的时候会发现B把代码大面积改动了，甚至A得细心的看每一行代码，其实很有可能B只改一行代码，但是由于B格式化了代码，A没有格式化。这样会导致A花大量时间在合并代码上。为了避免这种问题的出现 ，建议在提交代码前进行格式化代码。另外一个问题就是代码格式化后对于阅读更加赏心悦目。原始代码：

格式化后：

IDEA中使用快捷键：

Ctr+Alt+L或者选中你要格式化的代码然后Ctr+Alt+L

以上是这段时间所遇到的，这里总结一下，希望对大家有用。大家对下面这段代码有何评价