web-dev-qa-db-fra.com

Quelle est la raison de ces règles PMD?

DataflowAnomalyAnalysis: Anomalie "DD" trouvée pour la variable "variable" (lignes "n1" - "n2").

DataflowAnomalyAnalysis: Anomalie "DU" trouvée pour la variable "variable" (lignes "n1" - "n2").

DD et DU semblent familiers ... Je veux dire dans des choses comme les tests et les analyses concernant les conditions pré et post les plus faibles, mais je ne me souviens pas des détails.

NullAssignment: Affecter un objet à null est une odeur de code. Pensez à refactoriser.

La définition d'un objet sur null ne faciliterait-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?

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

LocalVariableCouldBeFinal: la variable locale 'variable' pourrait être déclarée finale

Y a-t-il des avantages à utiliser les paramètres et les variables final?

LooseCoupling: évitez d'utiliser des types d'implémentation comme 'LinkedList'; utilisez plutôt l'interface

Si je sais que j'ai spécifiquement besoin d'un LinkedList, pourquoi n'en utiliserais-je pas un pour expliquer clairement mes intentions aux futurs développeurs? C'est une chose de renvoyer la classe la plus élevée dans le chemin de classe qui a du sens, mais pourquoi ne déclarerais-je pas mes variables comme ayant le sens le plus strict?

EviterSynchronizedAtMethodLevel: utiliser la synchronisation au niveau du bloc plutôt que la synchronisation au niveau de la méthode

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

EviterUtiliserShortType: N'utilisez pas le type court

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

javapmd
35
Thomas Owens

  • Les anomalies DD et DU (si je me souviens bien - 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 avant d'être lue. 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.

  • Assigner null à une variable locale pour "aider" le garbage collector est un mythe. PMD vous fait savoir que ce n'est qu'un encombrement contre-productif.

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

  • Spécifier les interfaces en termes de… eh bien, interfaces est une excellente pratique de conception. Vous pouvez facilement modifier les implémentations de la collection sans impact sur l'appelant. C'est à cela que servent les interfaces.

  • Je ne peux pas penser à de nombreux cas où un appelant aurait besoin d'un LinkedList, car il n'expose aucune API qui n'est pas ' t déclaré par une interface. Si le client s'appuie sur cette API, elle est disponible via la bonne interface.

  • La synchronisation au niveau du bloc permet à la section critique d'être plus petite, ce qui permet d'effectuer autant de travail simultanément que possible. Peut-être plus important encore, il permet l'utilisation d'un objet verrou qui est contrôlé en privé par l'objet englobant. De cette façon, vous pouvez garantir qu'aucun blocage ne peut se produire. En utilisant l'instance elle-même comme verrou, n'importe qui peut se synchroniser incorrectement sur celle-ci, provoquant un blocage.

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

33
erickson

Juste une note sur la question final.

Mettre "final" sur une variable fait qu'elle ne peut être assignée ne 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 considérer ces points:

  • toute variable avec 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, alors les variables NON marquées avec final changeront réellement.

Cela signifie que vous pouvez déjà voir en lisant la partie définition les variables à rechercher, car elles peuvent changer de valeur pendant le code, et le responsable peut mieux dépenser ses efforts car le code est plus lisible.

3
Thorbjørn Ravn Andersen

DataflowAnomalyAnalysis: Anomalie "DD" trouvée pour la variable "variable" (lignes "n1" - "n2").

DataflowAnomalyAnalysis: Anomalie "DU" trouvée pour la variable "variable" (lignes "n1" - "n2").

Aucune idée.

NullAssignment: Affecter un objet à null est une odeur de code. Pensez à refactoriser.

La définition d'un objet sur null ne faciliterait-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 pour être récupérés après le retour de la méthode. Les définir sur null ne fera aucune différence.

Etant donné que cela rendrait les développeurs moins expérimentés, cette affectation nulle peut être considérée comme une odeur de code.

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

LocalVariableCouldBeFinal: la variable locale 'variable' pourrait être déclarée finale

Y a-t-il des avantages à utiliser les paramètres et les variables final?

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 essaie d'affecter une valeur, le compilateur empêchera cette erreur de codage au type de compilation.

considère 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 était le paramètre utilisé, ce que vous ne comprenez pas, c'est POURQUOI la méthode burnTHeHouse est invoquée si les conditions ne sont pas remplies ( selon vos résultats)

Cela vous prendra un certain temps pour découvrir qu'à un moment donné au milieu, une personne change la référence, et que vous utilisez autre objet.

L'utilisation de final permet d'éviter ce genre de choses.

LooseCoupling: évitez d'utiliser des types d'implémentation comme 'LinkedList'; utilisez plutôt l'interface

Si je sais que j'ai spécifiquement besoin d'un LinkedList, pourquoi n'en utiliserais-je pas pour expliquer clairement mes intentions aux futurs développeurs? C'est une chose que de renvoyer la classe la plus élevée dans le chemin de classe qui a du sens, mais pourquoi ne déclarerais-je pas mes variables au 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 peut avoir un sens, mais en utilisant une interface, vous aidez votre auto (ou les autres) à le changer facilement quand il ne le fera pas.

Pour les petits projets personnels, cela peut ne pas avoir de sens du tout, mais puisque vous utilisez déjà un analyseur, je suppose que vous vous souciez déjà de la qualité du code.

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

EviterSynchronizedAtMethodLevel: utiliser la synchronisation au niveau du bloc plutôt que la synchronisation au niveau de la méthode

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

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

De plus, si vous synchronisez au niveau de la méthode, vous bloquerez tout 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.

EviterUtiliserShortType: N'utilisez pas le type court

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

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

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

Les odeurs de code sont davantage orientées vers la qualité du code que vers les optimisations de performances. Les conseils sont donc donnés aux programmeurs moins expérimentés et pour éviter les pièges, plutôt que pour améliorer la vitesse du programme.

De cette façon, vous pourriez économiser beaucoup de temps et de frustrations en essayant de changer le code pour l'adapter à une meilleure conception.

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

3
OscarRyz

La définition d'un objet sur null ne faciliterait-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?

La seule chose qu'il fait est de permettre à l'objet d'être GCd avant la fin de la méthode, ce qui est rarement nécessaire.

Y a-t-il des avantages à utiliser les paramètres et variables finaux?

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

Si je sais que j'ai spécifiquement besoin d'une LinkedList, pourquoi n'en utiliserais-je pas pour expliquer clairement mes intentions aux futurs développeurs?

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

C'est une chose de renvoyer la classe la plus élevée dans le chemin de classe qui a du sens, mais pourquoi ne déclarerais-je pas mes variables comme ayant le sens le plus strict?

Je ne me soucie pas beaucoup des variables ou des champs locaux, mais si vous déclarez un paramètre de méthode de type LinkedList, je vais vous traquer et vous blesser, car cela me rend impossible d'utiliser des choses comme Arrays.asList() et Collections.emptyList().

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

Le plus important est qu'il vous permet d'utiliser un objet moniteur dédié afin que seules les sections critiques s'excluent mutuellement, 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 mes données?

Parce que les types plus petits que int sont automatiquement promus en int pour tous les calculs et vous devez effectuer une conversion pour leur attribuer quoi que ce soit. Cela conduit à du code encombré et à beaucoup de confusion (en particulier lorsque la boîte automatique est impliquée).

1
Michael Borgwardt

EviterUtiliserShortType: N'utilisez pas le type court

  • Élément de liste

    court est 16 bits, compliment de 2 en Java

  • une courte opération mathématique avec quoi que ce soit dans la famille Integer en dehors d'un autre court nécessitera une conversion d'extension de signe d'exécution à la plus grande taille. fonctionner contre une virgule flottante nécessite une extension de signe et une conversion non triviale en IEEE-754.
  • ne peut pas trouver de preuve, mais avec un registre 32 bits ou 64 bits, vous n'économisez plus sur les "instructions du processeur" au niveau du bytecode. Vous garez une voiture compacte dans la place de stationnement d'une semi-remorque en ce qui concerne le registre du processeur.
  • Si vous optimisez votre projet au niveau du code octet, wow. juste wow. ; P
  • Je suis d'accord sur le côté conception d'ignorer cet avertissement pmd, pesez simplement la description précise de votre objet avec un `` court '' par rapport aux conversions de performances encourues.
  • à mon avis, les résultats de performance encourus sont minuscules sur la plupart des machines. ignorer l'erreur.
0
DefyGravity

Quels sont les avantages de la synchronisation au niveau des blocs par rapport à la synchronisation au niveau des méthodes? Synchroniser une méthode est comme faire un bloc synchronize(getClass()), et bloque toute la classe.

Peut-être que tu ne veux pas ça

0
user2427