Serge NOEL
287 lines
15 KiB
Plaintext
287 lines
15 KiB
Plaintext
<!DOCTYPE html>
|
|
<html lang="fr">
|
|
<!-- Updated by Hervé BLOREC <bzh56420@yahoo.fr> on 2016-07-10 -->
|
|
<head>
|
|
<title>JMRI: Analyse statique avec SpotBugs</title>
|
|
<meta name="author" content="Bob Jacobsen">
|
|
<meta name="keywords" content="JMRI technical code">
|
|
<!--#include virtual="/help/fr/parts/Style.shtml" -->
|
|
<meta http-equiv="content-type" content="text/html; charset=utf-8">
|
|
</head>
|
|
|
|
<body>
|
|
<!--#include virtual="/help/fr/parts/Header_fr.shtml" -->
|
|
|
|
<div id="mBody">
|
|
<!--#include virtual="Sidebar.shtml" -->
|
|
|
|
<div id="mainContent">
|
|
<!-- Page Body -->
|
|
|
|
<h1>JMRI: Analyse statique avec SpotBugs</h1>
|
|
SpotBugs est un outil qui peut examiner le code pour trouver d'éventuels problèmes. Il fait
|
|
un "analyse statique", en regardant à travers le code pour trouver certaines "mauvaises idées
|
|
connues": Les choses qui sont susceptibles de causer des problèmes
|
|
occasionnels/intermittents, mauvaise performance, etc Parce que ces genre de problèmes sont
|
|
difficile à trouver avec les tests, les trouver par l'inspection est souvent la seule
|
|
approche réaliste. Disposer d'un outil qui peut faire les inspections automatiquement, afin
|
|
qu'elles puissent se faire à chaque fois que quelque chose est changé, protège le code d'une
|
|
dégradation lente sans que quelqu'un le remarque jusqu'à ce qu'il soit trop tard.
|
|
<p>Pour plus d'informations sur SpotBugs, voir <a href="https://spotbugs.github.io">la page
|
|
d'accueil SpotBugs</a> .</p>
|
|
|
|
<p>Nous exécutons sous forme d'une routine SpotBugs comme une partie de notre <a href=
|
|
"ContinuousIntegration.shtml">processus continue d'intégration</a>. Vous pouvez voir les
|
|
résultats des plus récentes constructions en ligne <a href=
|
|
"https://jmri.ci.cloudbees.com/job/Development/job/FindBugs/lastBuild/">ici</a>.</p>
|
|
|
|
<p>Si SpotBugs trouve une erreur positive, un bug qui n'est pas réellemnt un bug, vous pouvez
|
|
l'éteindre avec une annotation tels que:</p>
|
|
|
|
<pre><code>
|
|
@edu.umd.cs.findbugs.annotations.SuppressFBWarnings("FE_FLOATING_POINT_EQUALITY","OK to compare floats, as even tiny differences should
|
|
trigger update")
|
|
</code></pre>Bien que Java lui-même estime qu'il est facultatif, nous avons besoin du deuxième
|
|
argument "justification". Expliquer pourquoi vous avez ajouté cette annotation pour supprimer un
|
|
message aidera celui qui vient après vous et tente de comprendre le code. Il aidera également à
|
|
vous assurer que vous comprenez bien la cause du rapport de bogue sous-jacent: Parfois, ce qui
|
|
semble un faux positif ne l'est vraiment pas. Les Annotations sans une clause de justification
|
|
seront périodiquement éliminées.
|
|
<p>Si vous avez besoin de mettre plus d'un type de message dans une annotation, utilisez la
|
|
syntaxe de tableau:</p>
|
|
|
|
<pre><code>
|
|
@edu.umd.cs.findbugs.annotations.SuppressFBWarnings("{type1},{type2}","why both are needed")
|
|
</code></pre>
|
|
<p>Il y a ausi des annotations Java et FingBugs qui peuvent vous aider à mieux comprendre
|
|
votre code. Parfois, ils vont lui donner suffisamment de compréhension, par exemple: quand
|
|
une variable peut être nulle, que ça ne va plus faire des erreurs de faux positifs. Pour en
|
|
savoir plus, voir les <a href=
|
|
"https://docs.oracle.com/javase/tutorial/java/annotations/">Annotations Java</a> et les
|
|
<a href="http://findbugs.sourceforge.net/manual/annotations.html">pages d'annotations
|
|
SpotBugs</a> .</p>
|
|
|
|
<p>Les bases d'annotations sont couverts dans un <a href=
|
|
"https://docs.oracle.com/javase/tutorial/java/annotations/">Tutoriel annotation Java</a>.</p>
|
|
|
|
<p>Il peut être utile de marquer le code avec une des annotaions suivantes de telle sorte que
|
|
SpotBugs fasse un bon travail de raisonnement à ce sujet:</p>
|
|
|
|
<ul>
|
|
<li><a href=
|
|
"http://findbugs.sourceforge.net/manual/annotations.html"><code>javax.annotation.Nonnull</code></a>
|
|
- L'element annoté ne doit pas être nul. Les champs annotés ne doivent pas être nuls après
|
|
la construction terminée. Les méthodes annotées doivent avoir des valeurs non-nulles
|
|
retournées Utiliser javax.annotation.ParametersAreNonnullByDefault pour définir pour toute
|
|
une classe. Préférer l'usage de <code>CheckForNull</code>.</li>
|
|
|
|
<li><a href=
|
|
"http://findbugs.sourceforge.net/manual/annotations.html"><code>javax.annotation.CheckForNull</code></a>
|
|
- La variable, paramètre ou valeur annotée peut avoir une valeur nulle, de sorte que tous
|
|
les utilisateurs devraient les traiter convenablement. S'il vous plaît mettre cela dans des
|
|
définitions de méthode pour signaler que la valeur de retournée doit être vérifié pour être
|
|
nulle</li>
|
|
|
|
<li><a href=
|
|
"http://findbugs.sourceforge.net/manual/annotations.html"><code>edu.umd.cs.findbugs.annotations.OverrideMustInvoke</code></a>
|
|
Utilisé pour annoter une méthode qui, si surchargée, doit (ou devrait) être super invoquée
|
|
dans le méthode redéfinie. Des exemples de tels procédés comprennent la finalisation () et
|
|
clone (). L'argument de la méthode indique quand la super invocation doit se produire: à
|
|
tout moment ( ANYTIME ), au début de la méthode dérogatoire ( FIRST ), ou à la fin de la
|
|
méthode dérogatoire ( LAST ), par défaut à tout moment, par exemple
|
|
<code>@OverrideMustInvoke ( valeur = ANYTIME )</code></li>
|
|
|
|
<li><a href=
|
|
"http://findbugs.sourceforge.net/manual/annotations.html"><code>javax.annotation.CheckReturnValue</code></a>
|
|
- annoter une méthode pour dire QUE la méthode n'a pas d'effets secondaires, donc il n'y a
|
|
aucun point en appelant sans vérifier sa valeur de retour</li>
|
|
|
|
<li><a href=
|
|
"http://jcip.net/annotations/doc/net/jcip/annotations/Immutable.html"><code>net.jcip.annotations.Immutable</code></a>
|
|
- Un objet de cettte classe ne peut pas être changé après avoir été créé. Ceci permet à la
|
|
fois une meilleure vérification de la logique et aussi simplifie l'usage pour vos
|
|
collègues, aussi il est bon de créer des classes qui ont cette propriété et de les
|
|
annoter.</li>
|
|
|
|
<li><a href=
|
|
"http://jcip.net/annotations/doc/net/jcip/annotations/ThreadSafe.html"><code>net.jcip.annotations.ThreadSafe</code></a>
|
|
- classes qui doivent être utilisables pour plusieurs threads.Fidbugs l'assume
|
|
généralement, mais il es bon de de le mettre dans une classe qui est prévue pour être
|
|
thread-safe comme un rappel pour de futures développeurs.</li>
|
|
</ul>
|
|
Pour avoir plus d'information à propos de ces annotations, SVP voir la <a href=
|
|
"http://jcip.net/annotations/doc/index.html">Page dans l'API Concurrency</a>.
|
|
<p>Nous n'utilisons pas ces annotations:</p>
|
|
|
|
<ul>
|
|
<li><a href=
|
|
"http://findbugs.sourceforge.net/manual/annotations.html"><code>javax.annotation.Nullable</code></a>
|
|
- cela ne signifie pas vraiment ce que les gens pensent qu'il fait, comme SpotBugs ne
|
|
vérifie pas vraiment pas quelque chose quand il est utilisé. De la documentation: SpotBugs
|
|
traitera les articles annotés comme s'ils n'avaient aucune annotation. Dans la pratique,
|
|
cette annotation est utile que pour des raisons impérieuses d'une annotation globale non
|
|
nulle. Utilisez javax.annotation.ParametersAreNullableByDefault pour le définir comme une
|
|
classe entière. Preférez l'usage de <code>CheckForNull</code>.</li>
|
|
</ul>
|
|
|
|
<h3>Suppression Avertissements</h3>
|
|
Nous avons désactivé les SpotBugs de routine de contrôle de certains types de conditions:
|
|
<dl>
|
|
<dt><a href=
|
|
"http://spotbugs.readthedocs.io/en/latest/bugDescriptions.html#ri-class-implements-same-interface-as-superclass-ri-redundant-interfaces">
|
|
RI_REDUNDANT_INTERFACES</a>
|
|
</dt>
|
|
|
|
<dd>Ce drapeaux au cas où une classe implémente une interface, et aussi hérite d'une
|
|
superclasse qui implémente déjà cette interface. Ceci est redondant et inutile, mais il ne
|
|
peut pas provoquer de dysfonctionnement du code. Nous avons assez d'entre eux que nousavons
|
|
éteint l'avertissement, et nous y reviendrons plus tard.</dd>
|
|
|
|
<dt><a href=
|
|
"http://spotbugs.readthedocs.io/en/latest/bugDescriptions.html#sic-could-be-refactored-into-a-named-static-inner-class-sic-inner-should-be-static-anon">
|
|
SIC_INNER_SHOULD_BE_STATIC_ANON</a> ,</dt>
|
|
|
|
<dt><a href=
|
|
"http://spotbugs.readthedocs.io/en/latest/bugDescriptions.html#sic-could-be-refactored-into-a-static-inner-class-sic-inner-should-be-static-needs-this">
|
|
SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS</a>
|
|
</dt>
|
|
|
|
<dd>Static opposé à non-static, les classes internes ( classes définies au cœur d'autres
|
|
classes ) prennent moins de place parce qu'ils ne maintiennent pas de références à l'objet
|
|
contenant. Cet avertissement suggère de déplacer une classe anonyme interne (définie dans
|
|
la ligne du code) à une classe régulière (non définie en ligne) ainsi elles peuvent être
|
|
statiques. Bien que ce soit probablement une petite amélioration, c'est un peu de travail
|
|
pour une petite amélioration. Nous avons assez de ceux où nous avons coupé les
|
|
avertissements, et et nous y reviendront plus tard.</dd>
|
|
|
|
<dt><a href=
|
|
"http://spotbugs.readthedocs.io/en/latest/bugDescriptions.html#sic-could-be-refactored-into-a-named-static-inner-class-sic-inner-should-be-static-anon">
|
|
SIC_INNER_SHOULD_BE_STATIC_ANON</a>, <a href=
|
|
"http://spotbugs.readthedocs.io/en/latest/bugDescriptions.html#sic-could-be-refactored-into-a-static-inner-class-sic-inner-should-be-static-needs-this">
|
|
SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS</a></dt>
|
|
|
|
<dd>Statique, comme opposé à non-statique, Les inner classes ( classes définies au sein
|
|
d'autres classes ) prennent peu de place parce qu'lles ne permettent pas de maintenir les
|
|
références à l'objet contenant. Cet avertissement suggère de déplacer une classe interne
|
|
anonyme ( définie dans la ligne du code ) vers une classe régulière ( non défini pas en
|
|
ligne ) ainsi elle peut être rendue statique.Bien que ce soit probablement une petite
|
|
amélioration, c'est un peu de travail pour une petite amélioration. Nous en avons assez
|
|
aussi nous avons eteint l'avertissement, et il reviendra un peu plus tard.</dd>
|
|
|
|
<dt><a href=
|
|
"http://spotbugs.readthedocs.io/en/latest/bugDescriptions.html#pzla-consider-returning-a-zero-length-array-rather-than-null-pzla-prefer-zero-length-arrays">
|
|
PZLA_PREFER_ZERO_LENGTH_ARRAYS</a>
|
|
</dt>
|
|
|
|
<dd>Que doit faire une méthode qui retourne un tableau de valeurs quand il n'y en a pas?
|
|
Retourner "Nulle", opposé à un tableau vides, exige tout le code d'appel pour traiter un
|
|
cas particulier. Dans beaucoup de cas, retourner un tableau vide rend le code plus simple.
|
|
Mais pour du code existant, la simplification est marginale. Comme cela est un problème de
|
|
conception, mais il surgit souvent nous avons supprimé ceci pour nous focaliser maintenant
|
|
sur des problèmes plus presssants</dd>
|
|
|
|
<dt>Code Malveillant</dt>
|
|
|
|
<dd>C'est une classe d'avertissement centrée autour d'une idée que les données et les
|
|
méthodes de codes ne doivent pas être trop visibles spécialement en statique. Ceci est
|
|
vrai, mais JMRI n'est pas une bibliothèque trempée qui est publiée dans un monde de gens
|
|
qui essaient de le briser, aussi ces changements ne sont pas une grande priorité.</dd>
|
|
|
|
<dt>Nm</dt>
|
|
|
|
<dd>La convention est que les noms de cette clase démarre avec une lettre capitale et les
|
|
noms de procédé ( donné et code ) avec une lettre minuscule.</dd>
|
|
|
|
<dt>Se,SvVI</dt>
|
|
|
|
<dd>Cette une grande classe d'averissementss associées avec la sérialisation Java. JMRI
|
|
n'utilise pas la sérialisation et il est peu probable qu'il le fasse à l'avenir, de sorte
|
|
que nous supprimons ces derniers pour élever la qualité moyenne des avertissements
|
|
émis.</dd>
|
|
</dl>
|
|
|
|
<h3>Arrière Plan</h3>
|
|
|
|
<p>Simon White a ajouté le support FindBugs à notre Chaine de construction basée sur Ant
|
|
pendant le développement du JMRI 2.5.5. Sa note sur ceci suit...</p>
|
|
|
|
<p>Comme demande de fonctionnalité par 1716873, j'ai ajouté une tâche Ant pour exécuter
|
|
SpotBugs. Ceci va produire un rapport en HTML dans le méme emplacement que le JMRI jar (
|
|
c'est à dire le plus haut niveau du répertoire projet ). Notez la nouvelle tâche exécute en
|
|
premier ant dist parce SpotBugs examine le dossier jmri.jar.</p>
|
|
Pour exécuter la tâche:
|
|
<ul>
|
|
<li>Installer SpotBugs ( pour moi j'ai mis cela dans C:/SpotBugs-3.1.1 )</li>
|
|
|
|
<li>soit exécuter <code>ant-Dspotbugs.home=C:/SpotBugs-4.2.3 spotbugs ( remplaéant le
|
|
paramètre de votre emplacement d'installation )</code> ou modifier le build.xml et modifier
|
|
le paramètre commenté de spotbugs.home à votre emplacement d'installation, puis exécutez
|
|
<code>ant spotbugs</code></li>
|
|
</ul>
|
|
Sur mon ancienne machine il faut environ 20 minutes, mais votre durée peut varier.
|
|
<p>Notez que dans le build.xml j'ai mis le réglage maximal de mémoire-Xmx pour le tâche
|
|
SpotBugs pour 1024m. Si votre système a plus de mémoire, la stimuler peut accélérer les
|
|
choses.</p>
|
|
|
|
<p>L'exécution de ceci sur JMRI 2.5.4 donné les résultats suivants:</p>
|
|
|
|
<table border="1" summary="">
|
|
<tr>
|
|
<td>Avertissements Mauvaise pratique</td>
|
|
<td>164</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Avertissements Correction</td>
|
|
<td>77</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Avertissements expérimentaux</td>
|
|
<td>7</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Avertissements vulnérabilité code malveillant</td>
|
|
<td>221</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Avertissements multithread exactitude</td>
|
|
<td>90</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Avertissements Performance</td>
|
|
<td>459</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Avertissements Louche</td>
|
|
<td>304</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th>Total</th>
|
|
<th>1322</th>
|
|
</tr>
|
|
</table>
|
|
|
|
<p>Beaucoup de travail a été fait dans JMRI pendant le cycle de libération 2.12 pour amener
|
|
le compteur de bug à zéro. Le <a href="ContinuousIntegration.shtml">serveur d'intégration
|
|
continue a fait</a> fonctionner SpotBugs deux fois par jour, ce qui permet aux développeurs
|
|
de voir les résultats de leur codage sans avoir à exécuter spotbugs eux-mémes.</p>
|
|
|
|
<p>Si vous regardez le code dans le dépôt Subversion JMRI, s'il vous plaît vérifier le
|
|
serveur CI et assurez-vous que vos modifications ne vont pas introduire de nouvelles
|
|
erreurs.</p>
|
|
|
|
<!--#include virtual="/help/fr/parts/Footer_fr.shtml" -->
|
|
</div>
|
|
<!-- closes #mainContent-->
|
|
</div>
|
|
<!-- closes #mBody-->
|
|
<script src="/js/help.js"></script>
|
|
</body>
|
|
</html>
|