写这样的Java方法等着被吐槽吧
写作文要做到段落清晰、每段思路流畅、每段主旨明确,要有一条清晰的线穿插整篇内容,编写程序代码和写作文是一个套路。一个类就像一篇小作文,类的单一职责就是小作文要叙述的主旨,类的方法就是小作文的段落,类的方法组合在一起就是小作文的整篇内容。类的方法要像文章的段落一样,有主旨,即只做一件事;思路清晰,即先做什么、后做什么。方法没写好就像作文的段落没写好一样,会让人有一种“写的都是啥”的反感。下面出现的方法,会让阅读代码的人很反感。
太随意的方法名
getAbc()。get是得到、抓住的意思,getAbc是想表达获取abc,但是没表达出如何获取的,get开头的方法应尽量是getter方法。
一个方法就是一个要执行的动作,应该以动词开头,结合名词、形容词,使用一些有意义、可搜索到的、读的出来的单词,方法名应该名副其实的描述方法体的内容,做到看其名知其意,如queryAbcFromDB。
参数列表太长
queryAbcBy(arg1,arg2...argn)。方法的参数列表太长,在使用时需要去关注每个参数传什么值、取哪个参数的值。更糟糕的情况,参数列表的参数名是arg1、arg2这种无意义的命名,这样的方法封装成jar给他人使用,对使用者来说很茫然,不知道如何使用。
如果一个方法的参数列表个数大于等于3,就需要将这些参数封装到一个类中,使用这个类作为参数,这样对使用者来说容易很多。
冗长的代码行
一个方法体的代码行数几十行,甚至上百行。阅读这样的方法,相信很多人的心里是拒绝的。冗长的代码行像写作文不分段落一样,把各种论述杂糅到一起,根本看不明白想描述什么,而且这样的方法一定做了不止一件事。
方法体要短小且只要一件事,做到职责单一,这样的方法一目了然,易于阅读和理解。判断一个方法是否不止做了一件事,那就是看是否能再拆出一个方法。在拆方法的时候,做到拆出来的方法是同一个抽象等级的,其实就像一个操作拆成很多步骤一样,每一步拆成单独的方法,而这些步骤在这个操作里是同一等级,顺序执行的。
深层次逻辑嵌套
if(x==1){
for(;;){
if(y==2){
if(z==3){
if(m==4){
}else{
}
}
}
}
}
这样的逻辑嵌套对阅读者来说就是一种折磨,在不断深入理解每层逻辑的同时,还要记住每层的逻辑标识,有时还需要跳回到原来某层的另一个逻辑。如果用这样的方式去写作文,正写着某一个主题,突然写另一个小片段,写着写着又突然写另一个小片段,不断变主题,等回到原主题的时候,会让人回想“刚刚写到哪了”,倒不如正事之前,把那些无关紧要的先做掉,或者合到一起。
对于这样深层次的逻辑嵌套,可以使用先否定、合并逻辑的方式去优化。如上面的伪代码不是先判断x==1嘛,可以先判断x!=1,y==2和z==3可以合并到一起,优化后的伪代码如下。
if(x!=1){
return ;
}
for(;;){
if(y!=2 || z!=3){
continue ;
}
if(m==4){
}else{
}
}
过早定义局部变量
String resultCode;
Response response;
if(hasParamEmpty){
//抛异常
...
}
//网络通信
...
resultCode和response过早的定义,有可能根本用不到,浪费存储资源。局部变量的定义要和使用到它的代码很近,用到再定义。