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

“如果尿不湿臭了,就换掉它”——语出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新技能,让我们的代码更漂亮。

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


猜你喜欢

转载自blog.51cto.com/10983206/2563566