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

“如果尿不湿臭了，就换掉它”——语出Beck奶奶。

“真想骂人，这代码谁写的？这变量是什么意思？这个写死的是什么意思？一句注释都没有？”。

这些话尽管很多人没说出口，但是心里多少都会想说。其实，真正开发中有人说你代码写的不好，并且有理有据，请接受并默默感谢他，因为这会使你成长。反之，不说你的人或许看似对你挺好，实则是“害”你。不出问题，你的领导或许不太会注意你的代码写的怎么样，而一旦出问题或需求有变化的话。可能就要排查问题，就得看你代码了。接手的人可能会因为看不懂你的代码而汇报给你的领导，然后你就被领导盯上了，后果可以自行脑补……

最近在给项目做代码审查的时候，总结出以下常见代码中的坏味道：

01 方法内容过长

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

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

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

02 代码重复

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

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

03 代码起名

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

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

04 神奇的魔法数字

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

(){
    ...
}{
    ...
}

当我去问前辈们的时候，人家回我一句就是：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

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

想写得一首漂亮的代码，推荐阅读以下书：

《代码整洁之道》

《重构：改善代码既有代码的设计》

没看过的相关怎么写好代码的书小伙伴，建议买这两本书看看。不一定是纸质版，电子版也行，目的就是咱们能get新技能，让我们的代码更漂亮。

始终相信，只要你稍微努力一点，就可以超过一大批人！

标签：总结,解决办法,格式化,味道,代码,注释,单词,方法
来源： https://blog.51cto.com/10983206/2563566