Talk about those weird code specifications - abuse of static imports

Because some requirements feel too weird, I collected them to entertain everyone.

code specification requirements

It is required that if the code can be imported statically, it must be imported statically.

If all the code is not statically imported, it will directly PR and refuse to merge.

Example:
equalsAnyIgnoreCase("test","test"); This must use import static org.apache.commons.lang3.StringUtils.equalsAnyIgnoreCase;

If we write:
StringUtils.equalsAnyIgnoreCase("test","test");

The wonderful architect requires that this must be modified to a static import.

Wonderful Interpretation

Java's static import (import static) is provided from JDK 1.5 version, its purpose is to reduce the amount of character input, improve the readability of the code, so as to better understand the program.

It is used to import a certain static member variable, method or all static member variables and methods of the specified class. If all the methods in a class are static methods declared with static, they can be imported directly by import static.

Misuse of static imports can make programs harder to read and harder to maintain.

After the static import, there is no need to write the class name in the code, but we know that the class is "a description of a class of things". Without the modification of the class name, the apparent meaning of the static attributes and static methods will be replaced by infinite methods, which will It makes it difficult for readers to figure out what its properties or methods represent, and even which class's properties (methods) have to think about it, especially when there are multiple static imports in a class and wildcards (*) are used This static import is a nightmare.

Still use StringUtils as an example.

StringUtils is not unique to Apache Commons.

Just pull a project, you can see how many StringUtils there are, and the method name equalsAnyIgnoreCase is not used in a package.

This method name may be used in many packages.

This weird requirement to force the use of static imports is simply outrageous, and it destroys the readability of the program at a certain stage.

In actual use, try not to use static imports for some public method names.

However, assertions used in some test classes for testing can still be imported statically.

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;

If the assertions used in some of our commonly used tests above.

Talk about those strange code specifications - abuse of static import - Java - OSSEZ

 

Guess you like

Origin blog.csdn.net/huyuchengus/article/details/131118426