Hable sobre esas extrañas especificaciones de código: abuso de importaciones estáticas

Debido a que algunos requisitos se sienten demasiado extraños, los recopilé para entretener a todos.

requisitos de especificación de código

Se requiere que si el código se puede importar de forma estática, se debe importar de forma estática.

Si todo el código no se importa estáticamente, PR directamente y se negará a fusionarse.

Ejemplo:
equalsAnyIgnoreCase("test","test"); Esto debe usar import static org.apache.commons.lang3.StringUtils.equalsAnyIgnoreCase;

Si escribimos:
StringUtils.equalsAnyIgnoreCase("test","test");

El arquitecto maravilloso requiere que esto se modifique a una importación estática.

Maravillosa interpretación

La importación estática de Java (importación estática) se proporciona a partir de la versión JDK 1.5, su propósito es reducir la cantidad de entrada de caracteres, mejorar la legibilidad del código para comprender mejor el programa.

Se utiliza para importar una determinada variable miembro estática, método o todas las variables miembro estáticas y métodos de la clase especificada. Si todos los métodos de una clase son métodos estáticos declarados con static, se pueden importar directamente mediante import static.

El mal uso de las importaciones estáticas puede hacer que los programas sean más difíciles de leer y de mantener.

Después de la importación estática, no es necesario escribir el nombre de la clase en el código, pero sabemos que la clase es "una descripción de una clase de cosas". Sin la modificación del nombre de la clase, el significado aparente de los atributos estáticos y los métodos estáticos serán reemplazados por métodos infinitos, lo que dificultará que los lectores descubran qué representan sus propiedades o métodos, e incluso qué propiedades de clase (métodos) tienen que pensar, especialmente cuando hay múltiples importaciones estáticas en se utilizan una clase y comodines (*). Esta importación estática es una pesadilla.

Todavía use StringUtils como ejemplo.

StringUtils no es exclusivo de Apache Commons.

Simplemente extraiga un proyecto, puede ver cuántos StringUtils hay y el nombre del método equalsAnyIgnoreCase no se usa en un paquete.

Este nombre de método puede usarse en muchos paquetes.

Este extraño requisito de forzar el uso de importaciones estáticas es simplemente escandaloso y destruye la legibilidad del programa en cierta etapa.

En el uso real, trate de no usar importaciones estáticas para algunos nombres de métodos públicos.

Sin embargo, las aserciones utilizadas en algunas clases de prueba para realizar pruebas aún se pueden importar de forma estática.

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;

Si las afirmaciones utilizadas en algunas de nuestras pruebas de uso común anteriores.

Hable sobre esas extrañas especificaciones de código - abuso de importación estática - Java - OSSEZ

 

Supongo que te gusta

Origin blog.csdn.net/huyuchengus/article/details/131118426
Recomendado
Clasificación