Quelle est la raison de ces règles PMD?

Question

DataflowAnomalyAnalysis: Trouvé 'DD'-anomalie de la variable "variable" (lignes 'n1'-'n2').

DataflowAnomalyAnalysis: Trouvé "DU" -anomalie de la variable "variable" (lignes 'n1'-'n2').

DD et DU son familier...je veux dire d'autres choses, comme d'essais et d'analyses relatives à la plus faible pré-et post-conditions, mais je ne me souviens pas des détails.

NullAssignment: Affectation d'un Objet à null est une odeur de code. Envisager refactoring.

Ne pas régler un objet d' null aider dans la collecte des ordures, si l'objet est un objet local (pas utilisé en dehors de la méthode)? Ou est-ce un mythe?

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

LocalVariableCouldBeFinal: Local la variable "variable" pourrait être déclarée final

Quels sont les avantages à l'utilisation d' final paramètres et variables?

LooseCoupling: Évitez d'utiliser la mise en œuvre des types comme 'LinkedList'; utilisation de l'interface au lieu de cela

Si je sais que j'ai précisément besoin d'un LinkedList, pourquoi n'aurais-je pas utiliser un pour faire mes intentions explicitement clair pour les futurs développeurs? C'est une chose pour revenir à la classe qui est la plus élevée jusqu'au chemin de classe qui fait sens, mais pourquoi aurais-je pas déclarer mes variables de le sens le plus strict?

AvoidSynchronizedAtMethodLevel: Utilisation au niveau du bloc plutôt qu'au niveau de la méthode la synchronisation

Quels sont les avantages au niveau du bloc de synchronisation ont plus de méthode de synchronisation de niveau?

AvoidUsingShortType: Ne pas utiliser le type court

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

Answer 1

• DD et DU anomalies (si je me souviens bien—je utiliser FindBugs et les messages sont un peu différentes) reportez-vous à la section attribution d'une valeur à une variable locale qui n'est jamais lu, généralement parce qu'il est réaffecté à une autre valeur avant même d'être lu. Un cas typique serait de l'initialisation d'une variable avec null lorsqu'elle est déclarée. Ne pas déclarer la variable, jusqu'à ce qu'il est nécessaire.

• Attribution d' null d'une variable locale dans le but "d'aider" le garbage collector est un mythe. PMD est de laisser vous savez que c'est juste contre-productif de l'encombrement.

• La spécification finale sur une variable locale devrait être très utile à un optimiseur, mais je n'ai pas d'exemples concrets de courant Ece de prendre avantage de cette astuce. J'ai trouvé utile dans le raisonnement sur la justesse de mon propre code.

• Spécification des interfaces en termes de... eh bien, interfaces est une grande conception de la pratique. Vous pouvez facilement changer les implémentations de la collection, sans impact sur les appelant à tous. C'est ce que les interfaces sont tout au sujet.

• Je ne peux pas penser à de nombreux cas où un appelant aurait besoin d'un LinkedList, puisqu'il n'a pas d'exposer une API qui n'est pas déclarée par une interface. Si le client s'appuie sur l'API, il est disponible par le biais de l'interface correcte.

• Au niveau du bloc de synchronisation permet à la section critique, plus petite, qui permet beaucoup de travail à faire en même temps possible. Peut-être plus important encore, il permet l'utilisation d'un verrou d'objet qui est une société privée contrôlée par l'affichage de l'objet. De cette façon, vous pouvez garantir qu'aucun blocage peut se produire. À l'aide de l'instance elle-même comme un verrou, n'importe qui peut synchroniser de manière incorrecte, provoquant un blocage.

• Des opérandes de type short sont promues int dans toutes les opérations. Cette règle est de laisser vous savez que cette promotion est en cours, et vous pourriez aussi bien utiliser un int. Cependant, l'utilisation de l' short type pouvez économiser de la mémoire, donc si c'est un membre de l'instance, je serais probablement ignorer cette règle.

Answer 2

DataflowAnomalyAnalysis: Trouvé 'DD'-anomalie de la variable "variable" (lignes 'n1'-'n2').

DataflowAnomalyAnalysis: Trouvé "DU" -anomalie de la variable "variable" (lignes 'n1'-'n2').

Aucune idée.

NullAssignment: Affectation d'un Objet à null est une odeur de code. Envisager refactoring.

Ne pas régler un objet d' null aider dans la collecte des ordures, si l'objet est un objet local (pas utilisé en dehors de la méthode)? Ou est-ce un mythe?

Les objets dans les méthodes locales sont marqués pour être nettoyée une fois le retour de la méthode. Leur mise à null de ne pas faire toute la différence.

Depuis, il ferait moins d'expérience des développeurs de ce que c'est que nulle affectation de tout cela peut être considéré comme une odeur de code.

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

LocalVariableCouldBeFinal: Local la variable "variable" pourrait être déclarée final

Quels sont les avantages à l'utilisation d' final paramètres et variables?

Il de préciser que la valeur ne change pas au cours du cycle de vie de l'objet.

Aussi, si par hasard quelqu'un essayer d'attribuer une valeur, le compilateur va empêcher cette erreur de codage dans le type de compilation.

réfléchissez à 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 êtes chargé de résoudre un mystérieux bug de temps en temps, des brûlures de la maison.

Vous savez ce qu'étais le paramètre utilisé, ce que tu ne comprends pas, c'est POURQUOI l' burnTHeHouse méthode est invoquée, si les conditions ne sont pas remplies ( selon vos constatations )

- Il vous prendre un certain temps pour trouver qu'à un certain moment dans le milieu, la somone changement de la référence, et que vous utilisez d'autres objets.

À l'aide de final aider à prévenir ce genre de choses.

LooseCoupling: Évitez d'utiliser la mise en œuvre des types comme 'LinkedList'; utilisation de l'interface au lieu de cela

Si je sais que j'ai précisément besoin d'un LinkedList, pourquoi n'aurais-je pas utiliser un pour faire mes intentions explicitement clair pour les futurs développeurs? C'est une chose pour revenir à la classe qui est la plus élevée jusqu'au chemin de classe qui fait sens, mais pourquoi aurais-je pas déclarer mes variables de le sens le plus strict?

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

Aujourd'hui, LinkedList pourrait faire sens, mais en utilisant une interface vous aider votre auto ( ou autres ) pour changer facilement quand il l'habitude.

Pour les petits, des projets personnels, cela peut ne pas faire sens, mais puisque vous êtes à l'aide d'un analyseur déjà, je suppose que vous vous souciez de la qualité de code déjà.

Il vous permet également de moins expérimentés développeur pour créer de bonnes habitudes. [ Je ne dis pas que vous êtes l'un, mais l'analyseur ne vous connais pas ;) ]

AvoidSynchronizedAtMethodLevel: Utilisation au niveau du bloc plutôt qu'au niveau de la méthode la synchronisation

Quels sont les avantages au niveau du bloc de synchronisation ont plus de méthode de synchronisation de niveau?

La plus petite synchronisée de la section le mieux. C'est tout.

Aussi, si vous effectuez une synchronisation au niveau de la méthode que vous allez bloquer l'ensemble de l'objet. Lors de la synchronisation au niveau du bloc, vous venez de le synchroniser section spécifique, dans certains cas, c'est ce dont vous avez besoin.

AvoidUsingShortType: Ne pas utiliser le type court

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

Je n'ai jamais entendu parler de cela, et je suis d'accord avec vous :) je n'ai jamais utiliser courte mais.

Ma conjecture est que, en ne l'utilisant, vous aurez été d'aider votre auto à la mise à niveau vers int de façon transparente.

Code odeurs sont plus orientés vers la qualité du code que de l'optimisation des performances. Donc les conseils sont donnés pour les moins de programmeurs expérimentés et à éviter les pièges, que d'améliorer la vitesse.

De cette façon, vous pouvez économiser beaucoup de temps et des frustrations lorsque vous tentez de modifier le code pour l'adapter à une meilleure conception.

Si le conseiller n'a pas de sens, il suffit de les ignorer, n'oubliez pas, vous êtes le développeur à la charge, et l'outil est juste qu'un outil. Si quelque chose va mal, vous ne pouvez pas blâmer l'outil, à droite?

Answer 3

Juste une remarque sur l' final question.

Mettre la "finale" sur une variable résultats ne cessibles une fois. Cela ne signifie pas nécessairement qu'il est plus facile à écrire, mais il veut certainement dire qu'il est plus facile à lire pour un avenir responsable.

Veuillez tenir compte de ces points:

• toute variable avec un final peut être immédiatement classé dans "pas de changement de valeur tout en regardant".
• implicitement, cela signifie que si toutes les variables qui ne vont pas changer sont marqués au final, les variables ne sont PAS marquées avec final en fait VA changer.

Cela signifie que vous pouvez déjà voir lors de la lecture par le biais de la partie définition des variables à regarder dehors pour, comme ils peuvent changer de valeur au cours du code, et que le responsable peut passer ses efforts mieux que le code est plus lisible.

Answer 4

Ne pas régler un objet à null aider à la collecte des ordures, si l' l'objet est un objet local (non utilisé en dehors de la méthode)? Ou est-ce une mythe?

La seule chose qu'il fait est de le rendre possible pour que l'objet soit Pgcd avant que la méthode de la fin, ce qui est rarement nécessaire.

Quels sont les avantages à l'utilisation de final paramètres et variables?

Elle rend le code un peu plus clair puisque vous n'avez pas à vous soucier de la valeur changé somwhere lorsque vous analysez le code. Plus souvent alors pas, vous n'avez pas besoin ou vous voulez changer la valeur d'une variable une fois qu'elle est, de toute façon.

Si je sais que j'ai précisément besoin d'un LinkedList, pourquoi n'aurais-je pas utiliser l'une de faire mes intentions explicitement clair les futurs développeurs?

Pouvez-vous penser à une raison pourquoi vous avez spécifiquement besoin d'un LinkedList?

C'est une chose de de retour de la classe la plus élevée de la chemin de classe qui fait sens, mais pourquoi aurais-je pas déclarer mes variables à de le sens le plus strict?

Je n'ai pas beaucoup de soins sur des variables locales ou des champs, mais si vous déclarez un paramètre d'une méthode de type LinkedList, je vais vous traquer et vous faire mal, car elle rend impossible pour moi d'utiliser des choses comme Arrays.asList() et Collections.emptyList().

Quels sont les avantages au niveau du bloc de synchronisation ont plus de méthode de synchronisation de niveau?

Le plus important est qu'il vous permet d'utiliser un moniteur dédié objet, de telle sorte que seules les sections critiques sont mutuellement exclusifs qui doivent être, plutôt que tout en utilisant le même moniteur.

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

Parce que les types plus petits que les int sont automtically promus en int pour tous les calculs et vous avez jeté à assigner n'importe quoi pour eux. Cela conduit à encombré de code et beaucoup de confusion (en particulier lorsque l'autoboxing est impliqué).

Answer 5

AvoidUsingShortType: Ne pas utiliser le type court

• Élément de la liste

  court est de 16 bits, 2 du compliment en java

• un court mathématiques operaion avec quoi que ce soit dans la famille entière à l'extérieur de l'autre court exigera l'exécution, l'extension du signe de la conversion à la plus grande taille. de fonctionnement contre une virgule flottante nécessite l'extension du signe et un non-trivial de conversion à la norme IEEE-754.
• ne peut pas trouver de preuve, mais avec un 32 bits ou 64 bits de registre, vous n'êtes plus des économies sur les "instructions du processeur" au niveau du bytecode. Vous êtes le stationnement d'une voiture compacte dans un semi-remorque de la place de stationnement autant que le processeur registre est concerné.
• Si vous êtes à l'optimisation de votre projet à l'octet de code de niveau de wow. juste wow. ;P
• Je suis d'accord sur le côté design de la méconnaissance de cet pmd avertissement, juste peser avec précision dans la description de votre objet avec un "court" par rapport à la charge de la performance des conversions.
• à mon avis, les engagés les performances sont de minuscules sur la plupart des machines. ignorer l'erreur.