Quelle est la raison de ces règles PMD?

Question

  

DataflowAnomalyAnalysis: trouvé   Anomalie 'DD' pour variable 'variable'   (lignes 'n1' - 'n2').

     

DataflowAnomalyAnalysis: trouvé   'Anomalie DU' pour variable 'variable'   (lignes 'n1' - 'n2').

DD et DU me semblent familiers ... Je veux dire des choses comme des tests et des analyses portant sur les conditions les plus faibles avant et après, mais je ne me souviens pas des détails.

  

NullAssignment: affectation d'un objet à   null est une odeur de code. Considérer   refactoring.

La définition d'un objet sur null ne faciliterait-elle pas le nettoyage de la mémoire, si l'objet est un objet local (non utilisé en dehors de la méthode)? Ou est-ce un mythe?

  

MethodArgumentCouldBeFinal: Paramètre   'param' n'est pas assigné et pourrait être   déclaré final

     

LocalVariableCouldBeFinal: Local   variable 'variable' pourrait être déclaré   final

L'utilisation de paramètres et de variables final est-elle avantageuse?

  

LooseCoupling: évitez d’utiliser   types de mise en œuvre comme   'LinkedList'; utiliser l'interface   au lieu de cela

Si je sais que j'ai spécifiquement besoin d'un LinkedList , pourquoi ne l'utiliserais-je pas pour préciser explicitement mes intentions aux futurs développeurs? C'est une chose de retourner la classe qui se trouve en haut du chemin de classe qui a du sens, mais pourquoi ne déclarerais-je pas mes variables comme ayant le sens le plus strict?

  

AvoidSynchronizedAtMethodLevel: Utiliser   niveau de bloc plutôt que niveau de méthode   synchronisation

Quels sont les avantages de la synchronisation au niveau des blocs par rapport à la synchronisation au niveau de la méthode?

  

AvoidUsingShortType: n'utilisez pas le   type court

Mes premières langues étaient le C et le C ++, mais dans le monde Java, pourquoi ne devrais-je pas utiliser le type qui décrit le mieux mes données?

Answer 1

• Les anomalies DD et DU (si mes souvenirs sont exacts - j'utilise FindBugs et les messages sont un peu différents) font référence à l'attribution d'une valeur à une variable locale qui n'est jamais lue, généralement parce qu'elle est réaffectée à une autre valeur auparavant. en cours de lecture. Un cas typique serait d’initialiser une variable avec null lorsqu’elle est déclarée. Ne déclarez pas la variable tant qu'elle n'est pas nécessaire.

• Affectation de null à une variable locale afin d’aider à " assister " le ramasse-miettes est un mythe. PMD vous informe que ce n’est que du fouillis contre-productif.

• La spécification de final sur une variable locale devrait être très utile pour un optimiseur, mais je n'ai pas d'exemple concret de JIT en cours tirant parti de cet indice. Je l’ai trouvé utile pour raisonner sur l’exactitude de mon propre code.

• La spécification d'interfaces en termes de… eh bien, interfaces est une excellente pratique de conception. Vous pouvez facilement modifier les implémentations de la collection sans avoir aucun impact sur l'appelant. C’est ce que sont les interfaces.

• Je ne peux pas penser à de nombreux cas dans lesquels un appelant aurait besoin d'une LinkedList , car il n'expose aucune API non déclarée par une interface. Si le client s'appuie sur cette API, elle est disponible via l'interface appropriée.

• La synchronisation au niveau des blocs permet de réduire la taille de la section critique, ce qui permet de faire le plus de travail possible simultanément. Peut-être plus important encore, il permet l’utilisation d’un objet verrou contrôlé de manière privée par l’objet englobant. De cette façon, vous pouvez garantir qu’aucune impasse ne peut se produire. En utilisant l'instance elle-même comme verrou, toute personne peut effectuer une synchronisation incorrecte, provoquant ainsi un blocage.

• Les opérandes de type short sont promus en int dans toutes les opérations. Cette règle vous indique que cette promotion est en cours et vous pouvez également utiliser un int . Cependant, l'utilisation du type short peut économiser de la mémoire. Par conséquent, s'il s'agit d'un membre d'instance, j'ignorerais probablement cette règle.

Answer 2

  

DataflowAnomalyAnalysis: trouvé   Anomalie 'DD' pour variable 'variable'   (lignes 'n1' - 'n2').

     

DataflowAnomalyAnalysis: trouvé   'Anomalie DU' pour variable 'variable'   (lignes 'n1' - 'n2').

Aucune idée.

  

NullAssignment: affectation d'un objet à   null est une odeur de code. Considérer   refactoring.

     

La définition d'un objet sur null ne contribuerait-elle pas à la récupération de place, si l'objet est un objet local (non utilisé en dehors de la méthode)? Ou est-ce un mythe?

Les objets dans les méthodes locales sont marqués comme des déchets ramassés une fois que la méthode est retournée. Les définir sur null ne fera aucune différence.

Etant donné que cela réduirait le nombre d'expériences des développeurs, une assignation nulle peut être considérée comme une odeur de code.

  

MethodArgumentCouldBeFinal: Paramètre   'param' n'est pas assigné et pourrait être   déclaré final

     

LocalVariableCouldBeFinal: Local   variable 'variable' pourrait être déclaré   final

     

L'utilisation de paramètres et de variables final est-elle avantageuse?

Il est plus clair que la valeur ne changera pas pendant le cycle de vie de l'objet.

De plus, si par hasard quelqu'un essaye d'attribuer une valeur, le compilateur empêchera cette erreur de codage lors de la compilation.

considérez ceci:

 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();
     }
  } 

Supposons que vous soyez chargé de résoudre un mystérieux bug qui brûle de temps en temps la maison.

Vous savez quel paramètre a été utilisé et ce que vous ne comprenez pas est POURQUOI la méthode burnTHeHouse est invoquée si les conditions ne sont pas remplies (selon vos résultats)

Il vous faut un certain temps pour découvrir qu’à un moment donné au milieu, quelqu'un change la référence et que vous utilisez un autre objet.

L'utilisation de final aide à empêcher ce genre de choses.

  

LooseCoupling: évitez d’utiliser   types de mise en œuvre comme   'LinkedList'; utiliser l'interface   au lieu de cela

     

Si je sais que j'ai spécifiquement besoin d'une LinkedList , pourquoi ne l'utiliserais-je pas pour préciser explicitement mes intentions aux futurs développeurs? C'est une chose de retourner la classe qui se trouve en haut du chemin de classe qui a du sens, mais pourquoi ne déclarerais-je pas mes variables comme ayant le sens le plus strict?

Il n'y a pas de différence, dans ce cas. Je pense que puisque vous n’utilisez pas de fonctionnalités spécifiques à LinkedList , la suggestion est juste.

Aujourd'hui, LinkedList pourrait avoir un sens, mais en utilisant une interface, vous aidez votre personne (ou d’autres) à la changer facilement quand elle ne le fait pas.

Pour les petits projets personnels, cela n’a aucun sens, mais comme vous utilisez déjà un analyseur, je suppose que la qualité du code vous préoccupe déjà.

Aide également les développeurs moins expérimentés à créer de bonnes habitudes. [Je ne dis pas que vous en êtes un mais l'analyseur ne vous connaît pas;)]

  

AvoidSynchronizedAtMethodLevel: Utiliser   niveau de bloc plutôt que niveau de méthode   synchronisation

     

Quels sont les avantages de la synchronisation au niveau des blocs par rapport à la synchronisation au niveau de la méthode?

Plus la section synchronisée est petite, mieux c'est. C'est ça.

En outre, si vous synchronisez au niveau de la méthode, vous bloquez l'intégralité de l'objet. Lorsque vous synchronisez au niveau du bloc, vous synchronisez simplement cette section spécifique, dans certaines situations, c'est ce dont vous avez besoin.

  

AvoidUsingShortType: n'utilisez pas le   type court

     

Mes premières langues étaient le C et le C ++, mais dans le monde Java, pourquoi ne devrais-je pas utiliser le type qui décrit le mieux mes données?

Je n’ai jamais entendu parler de cela, et je suis d’accord avec vous :) Je n’ai jamais utilisé short cependant.

Je suppose qu'en ne l'utilisant pas, vous vous aiderez à vous mettre à niveau vers int de manière transparente.

Les odeurs de code sont davantage axées sur la qualité du code que sur l'optimisation des performances. Les conseils sont donc donnés aux programmeurs moins expérimentés et pour éviter les pièges que pour améliorer la vitesse du programme.

De cette façon, vous pourriez économiser beaucoup de temps et de frustration en essayant de modifier le code pour l’améliorer.

Si le conseil n’a pas de sens, ignorez-les, rappelez-vous, vous êtes le développeur responsable, et l’outil n’est en réalité qu’un outil. Si quelque chose ne va pas, vous ne pouvez pas blâmer l'outil, non?

Answer 3

Juste une note sur la question finale .

Mise en " final " sur une variable, elle ne peut être assignée qu'une fois . Cela ne signifie pas nécessairement qu'il est plus facile d'écrire, mais cela signifie certainement qu'il est plus facile de lire pour un futur responsable.

Veuillez tenir compte de ces points:

• toute variable associée à un final peut être immédiatement classée dans " ne changera pas de valeur en regardant "..
• implicitement, cela signifie que si toutes les variables qui ne changeront pas sont marquées avec final, les variables NON marquées avec final changeront réellement.

Cela signifie que, lors de la lecture de la partie définition, vous pouvez déjà voir quelles variables doivent être surveillées, car elles peuvent changer de valeur pendant le code, et le responsable de la maintenance peut mieux utiliser ses efforts car le code est plus lisible.

Answer 4

  

Ne définirait pas un objet sur null   aider à la collecte des ordures, si le   objet est un objet local (non utilisé   en dehors de la méthode)? Ou est-ce un   mythe?

La seule chose qu'il permet, c’est possible que l’objet soit converti avant la fin de la méthode, ce qui est rarement nécessaire.

  

Y at-il des avantages à utiliser les paramètres et les variables finales?

Cela rend le code un peu plus clair puisque vous n’avez pas à vous soucier de la valeur modifiée quelque part lorsque vous analysez le code. Plus souvent, vous n'avez pas besoin ou ne voulez pas changer la valeur d'une variable une fois qu'elle est définie.

  

Si je sais que j'ai particulièrement besoin d'un   LinkedList, pourquoi n’en utiliserais-je pas un pour   préciser clairement mes intentions à   futurs développeurs?

Pouvez-vous penser à une raison pour laquelle vous auriez spécifiquement besoin d'un LinkedList?

  

C'est une chose à   retourner la classe qui est la plus haute de la   chemin de classe qui a du sens, mais pourquoi   est-ce que je ne déclarerais pas que mes variables sont   du sens le plus strict?

Les variables ou les champs locaux ne m'intéressent pas beaucoup, mais si vous déclarez un paramètre de méthode de type LinkedList , je vous traquerai et vous blesserai, car cela me rend impossible utilisez des éléments tels que Arrays.asList () et Collections.emptyList () .

  

Quels sont les avantages de la synchronisation au niveau des blocs par rapport à la synchronisation au niveau de la méthode?

Le plus important est qu’il vous permet d’utiliser un objet moniteur dédié de sorte que seules les sections critiques qui s’excluent mutuellement doivent être exclus, plutôt que tout ce qui utilise le même moniteur.

  

dans le monde Java, pourquoi ne devrais-je pas   utiliser le type qui décrit le mieux mon   données?

Parce que les types plus petits que int sont automatiquement promus int pour tous les calculs et que vous devez les affecter pour leur affecter quoi que ce soit. Cela conduit à un code encombré et à beaucoup de confiance (surtout lorsque l'autoboxing est impliqué).

Answer 5

AvoidUsingShortType: n'utilisez pas le type court

• Élément de liste

  short est 16 bits, le complément de 2 en java

• un opéraion mathématique court avec tout ce qui appartient à la famille Integer en dehors d’un autre court métrage nécessitera une conversion de l’extension du signe d’exécution en taille plus grande. fonctionner en virgule flottante nécessite une extension de signe et une conversion non triviale en IEEE-754.
• ne trouve pas de preuve, mais avec un registre 32 bits ou 64 bits, vous ne sauvegardez plus les "instructions de processeur" au niveau du bytecode. Vous garez une voiture compacte sur le parking d'une semi-remorque en ce qui concerne le registre des transformateurs.
• Si vous optimisez votre projet au niveau du code d'octet, wow. juste wow. ; P
• Je suis d'accord sur le point de vue conceptuel d'ignorer cet avertissement pmd. Pesez simplement en décrivant votre objet avec un "court" par rapport aux conversions de performances induites.
• à mon avis, les résultats obtenus sont minimes sur la plupart des machines. ignorer l'erreur.

Answer 6

  

Quels avantages le niveau de bloc   la synchronisation a sur le niveau de la méthode   synchronisation?   Synchroniser une méthode revient à faire un bloc synchronize (getClass ()) et bloque toute la classe.

Peut-être que vous ne voulez pas que