Regla de comprobación para evitar la invocación de algunos métodos y constructores

Question

¿Es posible utilizar Checkstyle para prohibir el uso de algunos constructores o métodos que usan valores predeterminados dependientes del sistema (configuración regional, juego de caracteres, etc.). Prefiero aplicar una política donde el programador debe ser explícito sobre los valores dependientes del sistema. Por lo que considero los siguientes artículos a ser peligroso:

• todos los constructores de java.io.FielWriter
  • utilizando dependiente del sistema de codificación
• la OutputStreamWriter(OutputStream os) constructor del java.io.OutputStreamWriter
  • usando dependiente del sistema de codificación
• del java.lang.String.toLowerCase() método
  • usando por defecto del sistema local
• El java.util.Calendar.getInstance() método
  • usando regional predeterminada del sistema y por defecto la zona horaria

(la lista sigue, se obtiene el imagen).

¿Es posible aplicar esto usando Checkstyle 5.5?

Answer 1

No puede hacer esto de forma predeterminada. Sin embargo, puede implementar su propio comprobador que verifica estos métodos.

La primera opción es usar Miscelánea-> Regexp. Obviamente, esto solo es posible si puedes encontrar infracciones con una expresión regular. Deberá establecer illegalPattern = true. Este sería un buen lugar para comenzar, creo.

La segunda opción es crear su propio cheque. Ver Writing Checks.

Existen limitaciones para escribir verificadores. Lo primero y más importante es que no puedes ver otros archivos. No hay ninguna verificación cruzada. Desde el sitio:

1. No se puede determinar el tipo de una expresión.
2. No puede ver el contenido de otros archivos. (Aunque se puede guardar archivos procesados ​​para su uso posterior)

Esto significa que no se puede poner en práctica algunas de la inspección de código características que están disponibles en entornos de desarrollo avanzadas como IntelliJ IDEA. Para el ejemplo , no podrá implementar una comprobación que encuentre moldes de tipo redundantes o métodos públicos no utilizados.

Así que no se pudo comprobar, por ejemplo, que el java está llamando a un método que tiene una alternativa con una configuración regional. Puede usar una lista negra de métodos a los que no tiene permitido llamar. Entonces, por ejemplo, las llamadas al nuevo FileWriter() verificarían el número de parámetros pasados, o similares.

Answer 2

creo un procesador de anotación sería más adecuado para esta tarea. De Matthew Farwell's answer "No se puede determinar el tipo de expresión".

Supongamos que utiliza un jar de terceros que contiene la clase FancyWriter que extiende FileWriter. Usted ilegalmente puso un x = new FancyWriter () ; en su código. CheckStyle no lo encontrará porque está usando expresiones regulares y no es lo suficientemente inteligente como para saber que FancyWriter es un FileWriter. Creo que podrías escribir un procesador de anotaciones que descubra que FancyWriter es realmente un FileWriter y es ilegal.

OTH, alguien, en teoría, podría escribir una extensión de una clase ilegal que elimine la dependencia del sistema. Por ejemplo, supongamos que FileWriter tiene un método en el que obtiene la codificación del sistema. Si LegalWriter amplía FileWriter y anula el método, entonces no deberíamos rechazar LegalWriter simplemente por b/c extendió una clase ilegal.

Si está utilizando frascos de terceros, ¿cómo sus clases son legales. Solo porque no extiendan una clase ilegal, no significa que no la usen. Entonces, si usa una de sus clases, su código depende del sistema.

Answer 3

Como Matthew y emory indicados, no hay una solución perfecta con el estilo de verificación. Aquí está mi sugerencia:

• No prohíba solo algunos constructores, sino que prohíba a todos los constructores de las clases afectadas. Luego crea tu propia subclase, que oculta los constructores prohibidos. Por ejemplo, cree un patrón de estilo de cheque "FileWriter\(" y una subclase SystemIndependentFileWriter con solo algunos de los constructores de la superclase.
• crear el patrón "toLowerCase()" y la esperanza, que nadie ha creado un método con el mismo nombre. Or use FindBugs to catch this one.
• crear un patrón Checkstyle "Calendar.getInstance()". No veo un problema con eso.

Esperemos que arroje solo algunos falsos positivos, que podrían incluirse en la lista de ignorados. Eventualmente necesita ajustarlo para atrapar saltos de línea u otros espacios en blanco extraviados.