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

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

代码规范要求

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

所有的代码如果不静态导入，就直接 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 的。

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

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

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

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

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

import static org.apache.commons.lang3.StringUtils.split;
import static org.hamcrest.CoreMatchers.instanceOf;
import static org.hamcrest.MatcherAssert.assertThat;
import static org.junit.Assert.assertEquals;

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

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