聊聊那些奇葩的代码规范 —— 滥用静态导入

因为有些要求感觉实是太过奇葩,收集下来娱乐下大家。

代码规范要求

要求如果代码可以静态导入的话,就必须要静态导入。

所有的代码如果不静态导入,就直接 PR 拒绝合并。

举例:
equalsAnyIgnoreCase("test","test"); 这个必须要使用 import static org.apache.commons.lang3.StringUtils.equalsAnyIgnoreCase;

如果我们写成:
StringUtils.equalsAnyIgnoreCase("test","test");

奇葩的架构师,要求这个必须要修改为静态导入。

奇葩解读

Java 的静态导入 (import static) 是从 JDK 1.5 版本开始提供的,其目的是为了减少字符输入量,提高代码的可阅读性,以便更好地理解程序。

用于导入指定类的某个静态成员变量、方法或全部的静态成员变量、方法。如果一个类中的方法全部是使用 static 声明的静态方法,则在导入时就可以直接使用 import static 的方式导入。

滥用静态导入会使程序更难阅读,更难维护。

静态导入后,代码中就不用再写类名了,但是我们知道类是“一类事物的描述”,缺少了类名的修饰,静态属性和静态方法的表象意义就会被无限方法,这会让阅读者很难弄清楚其属性或方法代表何以,甚至是哪一个类的属性(方法)都要思考想一下,特别是在一个类中有多个静态导入的时候还使用了通配符(*)这个静态导入简直是个噩梦。

还是用 StringUtils 来举例。

不是只 Apache Commons 才有 StringUtils 的。

 

2023-06-08_12-10-23

 
随便拉个项目,你看看就有多少个 StringUtils,同时 equalsAnyIgnoreCase 这个方法名也不是在一个包使用的。

可能在很多包中都用了这个方法名。

这种奇葩的强制使用静态导入的要求,简直是令人发指,在特定阶段的时候破坏了程序的可读性。

在实际使用的时候,对于一些公共方法名,尽量不要使用静态导入。

但是针对测试的一些测试类中使用的断言,还是可以使用静态导入的。


import static org.hamcrest.CoreMatchers.instanceOf;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.junit.Assert.assertEquals;

如果上面我们常用的一些测试中使用的断言。

 

https://www.ossez.com/t/topic/14492

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章