java - optica - ¿Cuál es el motivo de estas reglas PMD?

pmd netbeans

Question

DataflowAnomalyAnalysis: se encontró la ''anomalía DD'' para la variable ''variable'' (líneas ''n1'' - ''n2'').

DataflowAnomalyAnalysis: se encontró la anomalía ''DU'' para variable ''variable'' (líneas ''n1'' - ''n2'').

DD y DU suenan familiares ... Quiero decir en cosas como pruebas y análisis relacionados con las condiciones pre y post más débiles, pero no recuerdo los detalles.

Asignación Nula: Asignar un Objeto a nulo es un olor a código. Considera refactorizar.

¿No establecería un objeto null para ayudar en la recolección de elementos no utilizados, si el objeto es un objeto local (no se usa fuera del método)? ¿O es eso un mito?

MethodArgumentCouldBeFinal: El parámetro ''param'' no está asignado y podría declararse final

LocalVariableCouldBeFinal: la variable local ''variable'' podría declararse final

¿Hay alguna ventaja en el uso de parámetros y variables final ?

LooseCoupling: Evite el uso de tipos de implementación como ''LinkedList''; usar la interfaz en su lugar

Si sé que específicamente necesito una LinkedList , ¿por qué no debería usar una para dejar mis intenciones explícitamente claras a los futuros desarrolladores? Una cosa es devolver la clase que está más arriba en la ruta de clase que tiene sentido, pero ¿por qué no declararía que mis variables son del más estricto sentido?

AvoidSynchronizedAtMethodLevel: utilice sincronización de nivel de bloque en lugar de método

¿Qué ventajas tiene la sincronización a nivel de bloque sobre la sincronización a nivel de método?

AvoidUsingShortType: no use el tipo corto

Mis primeros idiomas fueron C y C ++, pero en el mundo de Java, ¿por qué no debería usar el tipo que mejor describe mis datos?

Answer 1

¿No establecería un objeto nulo para ayudar en la recolección de elementos no utilizados, si el objeto es un objeto local (no se usa fuera del método)? ¿O es eso un mito?

Lo único que hace es posibilitar que el objeto sea GCd antes del final del método, lo que rara vez es necesario.

¿Hay alguna ventaja en el uso de parámetros y variables finales?

Hace el código algo más claro ya que no tiene que preocuparse por el valor que se cambia en algún lugar cuando se analiza el código. Más a menudo, entonces no es necesario o no quiere cambiar el valor de una variable una vez que se establece de todos modos.

Si sé que específicamente necesito una LinkedList, ¿por qué no debería usar una para dejar mis intenciones explícitamente claras a los futuros desarrolladores?

¿Puedes pensar en alguna razón por la cual necesitarías específicamente una LinkedList?

Una cosa es devolver la clase que está más arriba en la ruta de clase que tiene sentido, pero ¿por qué no declararía que mis variables son del más estricto sentido?

No me importan demasiado las variables o campos locales, pero si declaras un parámetro de método de tipo LinkedList , te perseguiré y haré daño, porque me impide usar cosas como Arrays.asList() y Collections.emptyList() .

¿Qué ventajas tiene la sincronización a nivel de bloque sobre la sincronización a nivel de método?

El más grande es que le permite usar un objeto de monitor dedicado para que solo aquellas secciones críticas sean mutuamente exclusivas que deben ser, en lugar de usar todo con el mismo monitor.

en el mundo de Java, ¿por qué no debería usar el tipo que mejor describe mis datos?

Debido a que los tipos más pequeños que int se promocionan automáticamente a int para todos los cálculos, debe bajarlos para asignarles algo. Esto lleva a un código desordenado y bastante confusión (especialmente cuando se trata de autoboxing).

Answer 2

¿Qué ventajas tiene la sincronización a nivel de bloque sobre la sincronización a nivel de método? Sincronizar un método es como hacer un bloque de synchronize(getClass()) , y bloquea toda la clase.

Quizás no quieras eso

Answer 3

DataflowAnomalyAnalysis: se encontró la ''anomalía DD'' para la variable ''variable'' (líneas ''n1'' - ''n2'').

DataflowAnomalyAnalysis: se encontró la anomalía ''DU'' para variable ''variable'' (líneas ''n1'' - ''n2'').

Ni idea.

Asignación Nula: Asignar un Objeto a nulo es un olor a código. Considera refactorizar.

¿No establecería un objeto null para ayudar en la recolección de elementos no utilizados, si el objeto es un objeto local (no se usa fuera del método)? ¿O es eso un mito?

Los objetos en los métodos locales se marcan como basura recolectada una vez que el método retorna. Establecerlos en nulo no hará ninguna diferencia.

Dado que haría menos desarrolladores de experiencia, lo que es una tarea nula puede ser considerado un olor a código.

MethodArgumentCouldBeFinal: El parámetro ''param'' no está asignado y podría declararse final

LocalVariableCouldBeFinal: la variable local ''variable'' podría declararse final

¿Hay alguna ventaja en el uso de parámetros y variables final ?

Hace más claro que el valor no cambiará durante el ciclo de vida del objeto.

Además, si por casualidad alguien intenta asignar un valor, el compilador evitará este error de codificación en el tipo de compilación.

considera esto:

 public void businessRule( SomeImportantArgument important )  {
      if( important.xyz() ){
          doXyz();
      }
      // some fuzzy logic here
      important = new NotSoImportant();
      // add for/if''s/while etc 

     if( important.abc() ){ // <-- bug
         burnTheHouse();
     }
  } 

Supongamos que está asignado a resolver algún error misterioso que de vez en cuando quema la casa.

Ya sabes cuál fue el parámetro utilizado, lo que no entiendes es POR QUÉ se invoca el método burnTHeHouse si no se cumplen las condiciones (de acuerdo con tus conclusiones)

Hace falta tiempo para descubrir que en algún punto en el medio, alguien cambia la referencia y que está utilizando otro objeto.

Usando ayuda final para prevenir este tipo de cosas.

LooseCoupling: Evite el uso de tipos de implementación como ''LinkedList''; usar la interfaz en su lugar

Si sé que específicamente necesito una LinkedList , ¿por qué no debería usar una para dejar mis intenciones explícitamente claras a los futuros desarrolladores? Una cosa es devolver la clase que está más arriba en la ruta de clase que tiene sentido, pero ¿por qué no declararía que mis variables son del más estricto sentido?

No hay diferencia, en este caso. Creo que dado que no está utilizando la funcionalidad específica de LinkedList , la sugerencia es justa.

Hoy en día, LinkedList podría tener sentido, pero al usar una interfaz puede ayudarse a sí mismo (u otros) a cambiarlo fácilmente cuando no lo necesite.

Para pequeños proyectos personales esto puede no tener ningún sentido, pero ya que está usando un analizador, creo que ya se preocupa por la calidad del código.

Además, ayuda al desarrollador menos experimentado a crear buenos hábitos. [No digo que seas uno, pero el analizador no te conoce;)]

AvoidSynchronizedAtMethodLevel: utilice sincronización de nivel de bloque en lugar de método

¿Qué ventajas tiene la sincronización a nivel de bloque sobre la sincronización a nivel de método?

Cuanto menor sea la sección sincronizada, mejor. Eso es.

Además, si sincroniza en el nivel de método, bloqueará el objeto completo. Cuando se sincroniza a nivel de bloque, simplemente sincroniza esa sección específica, en algunas situaciones eso es lo que necesita.

AvoidUsingShortType: no use el tipo corto

Mis primeros idiomas fueron C y C ++, pero en el mundo de Java, ¿por qué no debería usar el tipo que mejor describe mis datos?

Nunca he oído hablar de esto, y estoy de acuerdo contigo :) Aunque nunca he usado el corto.

Supongo que al no usarlo, te estarás ayudando a actualizar a int sin problemas.

Los olores de código están más orientados a la calidad del código que las optimizaciones de rendimiento. Entonces, los consejos se dan a los programadores menos experimentados y para evitar trampas, que para mejorar la velocidad del programa.

De esta forma, podría ahorrar mucho tiempo y frustraciones cuando intente cambiar el código para adaptarlo a un mejor diseño.

Si el consejo no tiene sentido, ignórelo, recuerde, usted es el desarrollador a cargo, y la herramienta es solo eso una herramienta. Si algo sale mal, no puedes culpar a la herramienta, ¿verdad?

Answer 4

AvoidUsingShortType: no use el tipo corto

• Artículo de lista

  corto es 16 bit, cumplido de 2 en java

• una breve operación matemática con cualquier elemento de la familia Integer fuera de otro corto requerirá una conversión de extensión de signo de tiempo de ejecución al tamaño más grande. operar contra un punto flotante requiere una extensión de signo y una conversión no trivial a IEEE-754.
• no puede encontrar la prueba, pero con un registro de 32 bits o 64 bits, ya no está guardando en ''instrucciones del procesador'' en el nivel de bytecode. Está estacionando un automóvil compacto en el estacionamiento de un semirremolque en lo que respecta al registro del procesador.
• Si está optimizando su proyecto en el nivel de código de bytes, wow. simplemente guau. ;PAG
• Estoy de acuerdo en el aspecto del diseño de ignorar esta advertencia PMD, simplemente ponderar con precisión la descripción de su objeto con una conversión ''corta'' frente a las conversiones de rendimiento incurridas.
• en mi opinión, los resultados de rendimiento incurridos son minúsculos en la mayoría de las máquinas. ignora el error

Answer 5

Solo una nota sobre la pregunta final .

Al poner "final" en una variable, se puede asignar solo una vez . Esto no significa necesariamente que sea más fácil escribir, pero ciertamente significa que es más fácil de leer para un futuro mantenedor.

Por favor considere estos puntos:

• cualquier variable con un final se puede clasificar de inmediato en "no cambiará el valor mientras se mira".
• por implicación significa que si todas las variables que no cambian son marcadas con final, entonces las variables NO marcadas con final realmente cambiarán.

Esto significa que ya puede ver al leer la parte de definición qué variables buscar, ya que pueden cambiar el valor durante el código, y el mantenedor puede gastar mejor sus esfuerzos ya que el código es más legible.

Answer 6

• Las anomalías de DD y DU (si recuerdo correctamente, utilizo FindBugs y los mensajes son un poco diferentes) se refieren a la asignación de un valor a una variable local que nunca se lee, generalmente porque se reasigna otro valor antes de leerse. Un caso típico sería inicializar alguna variable con null cuando se declara. No declare la variable hasta que sea necesaria.

• Asignar null a una variable local para "ayudar" al recolector de basura es un mito. PMD te deja saber que esto es solo un desorden contraproducente.

• Especificar el final en una variable local debería ser muy útil para un optimizador, pero no tengo ejemplos concretos de JIT actuales que aprovechen esta sugerencia. Lo he encontrado útil para razonar sobre la corrección de mi propio código.

• Especificar interfaces en términos de ... bueno, las interfaces es una gran práctica de diseño. Puede cambiar fácilmente las implementaciones de la colección sin afectar a la persona que llama. De eso se tratan las interfaces.

• No puedo pensar en muchos casos en los que un llamante requiera una LinkedList , ya que no expone ninguna API que no esté declarada por alguna interfaz. Si el cliente confía en esa API, está disponible a través de la interfaz correcta.

• La sincronización a nivel de bloque permite que la sección crítica sea más pequeña, lo que permite realizar tanto trabajo como sea posible. Quizás lo más importante es que permite el uso de un objeto de bloqueo que está controlado de forma privada por el objeto que lo rodea. De esta forma, puedes garantizar que no se produzca un punto muerto. Al usar la instancia en sí misma como un bloqueo, cualquiera puede sincronizar incorrectamente, causando un punto muerto.

• Los operandos de tipo short se promueven a int en cualquier operación. Esta regla te permite saber que esta promoción está ocurriendo, y también podrías usar un int . Sin embargo, usar el tipo short puede ahorrar memoria, así que si es un miembro de instancia, probablemente ignore esa regla.