C.2.1 Règles proposées par PMD
PMD ne fait pas de refactoring mais uniquement de la détection de code pathogène. La quantité de règles gérées par PMD est trop longue pour en faire la liste exhaustive. Les groupes des règles supportées par PMD sont les suivantes.
– Règles JSF basiques. – Règles JSP basiques.
– Règles de base : collection de bonnes pratiques que tout le monde doit suivre. – Règles pour accolades : ensemble de règles accolades.
– Règles de mise en œuvre du Clone : ensemble de règles qui permettent de trouver des usages discutables de la méthode clone().
12. http://it.slashdot.org/article.pl?sid=06/09/07/1423244 13. http://www.secologic.de/en/index
– Règles taille de code : contient un ensemble de règles qui permettent de trouver les problèmes liés la taille du code.
– Règles controversées : contient des règles qui, pour une raison quelconque, sont considé- rés comme controversée. Ils sont séparés ici pour permettre aux gens de choisir ce qu’ils voudront.
– Règles de constructeurs inutiles.
– Règles de couplage : Ce sont des règles qui trouvent des cas de couplage élevé ou inap- propriés entre des objets et des packages.
– Règles de conception : contient un ensemble de règles qui permettent de trouver des conceptions discutables.
– Règles Finalizer : Ces règles concernent les différents problèmes qui peuvent se produire avec des finaliseurs.
– Règles d’importations : ces règles concernent les différents problèmes qui peuvent sur- venir avec les importations.
– Règles J2EE
– Règles JavaBean : le jeu de règles JavaBeans capture les cas de règles de beans qui ne sont pas suivies
– Règles JUnit : Ces règles concernent les différents problèmes qui peuvent survenir avec des tests JUnit.
– Règles pour Jakarta Commons Logging : contient un ensemble de règles qui permettent de trouver des usages douteux de ce framework.
– Java règles d’enregistrement : Le jeu de règles Java enregistrement contient un ensemble de règles qui permettent de trouver des usages douteux de l’enregistreur.
– Règles de migration : contient des règles sur la migration d’une version de JDK à l’autre. – Règles de nommage.
– Règles d’optimisation : règles pour obtenir de meilleures performances à l’exécution. – Règles d’exception stricte : Ces règles prévoient des règles strictes sur la génération et
la capture d’exceptions.
– Règles pour String et StringBuffer : Ces règles concernent les différents problèmes qui peuvent se produire avec la manipulation de la classe String ou StringBuffer.
– Recommandations de sécurité : Ces règles vérifient l’application des directives de sécu- rité de Sun15
– Règles Code mort : contient un ensemble de règles qui permettent de trouver le code mort.
La liste détaillée de chacuns de ces groupe est visible à : http://pmd.sourceforge. net/rules/index.html
C.2.2 Refactor-it
Refactor-it propose en plus de ses refactorings, de nombreuses métriques listées en (Fig. C.2.2) ainsi que de l’audit de code :
– clauses catch dangereuses, – instructions throw dangereuses,
– clause throws redondantes , – blocs finally mal terminé, – sous-classes abstraite, – surcharge abstraite, – champs masqués,
– méthodes cachées statique, – pseudo-classes abstract, – modificateurs redondants, – méthodes ’staticalizable’, – importations non utilisés, – variables locales non utilisées, – déclarations vides,
– conversions String.toString (),
– littéraux booléens dans les comparaisons, – expressions exprimées redondantes, – expressions instanceof redondantes, – blocs détachés imbriqués,
– affectations de variables inutilisées,
– affectation de variables de contrôle de boucle, – equals () et hashCode () pas jumelés,
– switch sans default,
– switch traversé (pas de break), – réaffectations de paramètre, – auto-affectations,
– auto-affectation redondante,
– objets statiques accédés via des références, – code de debug,
C.2.3 Dependency finder
Les métriques proposées par Dependency finder sont listée ci-après. . Métriques basiques de méthode
Les mesures de base suivantes sont calculées pour chaque méthode :
– Nombre de caractères du nom (MNCC) : Nombre de caractères dans le nom de la méthode.
– Parameters (PARAM) : nombre de paramètres pour la méthode. De très longues si- gnatures sont souvent considérées comme un signe de mauvaise conception.
– Lignes de code (SLOC) : Nombre de lignes de code dans la méthode. Les commen- taires et les lignes vides ne sont pas comptés. Méthodes de grande taille sont généra- lement le signe d’une mauvaise conception.
– Variables locales (LVAR) : Nombre de variables locales pour la méthode.
La liste suivante sont des métriques pour les classes, les méthodes et les champs qui ont une dépendance avec la méthode mesurée.
même classe, qui dépendent de cette méthode.
– Sortants intra-classe d’entité dépendances (OICF) : Méthodes et domaines qui relèvent de la même classe dont cette méthode dépend.
– Entrants intra-package dépendances de la méthode (IIPM) : Méthodes dans d’autres classes du même paquet qui dépendent de cette méthode.
– Sortants intra-package dépendances entité (OIPF) : méthodes et champs dans les classes du même paquet dont cette méthode dépend.
– Entrants extra-package dépendances de la méthode (IEPM) : Méthodes à d’autres pa- quets qui dépendent de cette méthode.
– Sortants extra-package dépendances entité (OEPF) : méthodes et champs dans d’autres paquets dont cette méthode dépend.
– Sortants intra-package dépendances de la classe (OIPC) : classes dans le même pa- ckage dont cette méthode dépend.
– Sortants extra-package dépendances de la classe (OEPC) : classes dans d’autres pa- ckages dont cette méthode dépend.
. Métriques basiques de classe
Les mesures de base suivantes sont calculées pour chaque classe.
– Nombre de caractères du nom (CNCC) : Nombre de caractères dans le nom de la classe.
– Lignes de code (SLOC) : Nombre de lignes de code dans la classe. Les commentaires et les lignes vides ne sont pas comptés. Des classes de grande taille sont généralement un signe de mauvaise conception.
– Sous-classes (SUB) : Nombre de sous-classes directes de cette classe.
– Profondeur d’Héritage (DOI) : Combien d’intermédiaires il ya entre le sommet de la hiérarchie d’héritage et cette classe.
– Attributes (A) : Nombre d’attributs dans cette classe. – Méthodes (M) : Nombre de méthodes de cette classe
– Classes internes (IC) : Nombre de classes internes dans cette classe.
La liste suivante sont des métriques pour les classes, les méthodes et les champs qui ont une dépendance avec la méthode mesurée.
– Entrants intra-package dépendances (PII) : classes du même paquet qui dépendent de cette classe.
– Entrants extra-package dépendances (IEP) : classes en d’autres paquets qui dépendent de cette classe.
– Sortants intra-package dépendances (OIP) : classes du même paquet dont cette classe dépend.
– Sortants extra-package dépendances (OEP) : Classes d’autres paquets dont cette classe dépend.
– Entrants intra-package dépendances de la méthode (IIPM) : méthodes et les champs dans d’autres classes du même paquet qui dépendent de cette classe.
– Entrants extra-package dépendances de la méthode (IEPM) : Méthodes à d’autres pa- quets qui dépendent de cette classe.
. Métriques basiques d'ensembles
package est automatiquement un ensemble. Un fichier de configuration peut aussi définir d’autres ensembles arbitraires qui seront collectées et analysés en plus.
– Nombre de caractères du nom (GNCC) : Nombre de caractères dans le nom du groupe. – Classes (C) : Nombre de classes dans ce groupe.
– Interfaces (I) : nombre d’interfaces dans ce groupe . Métriques basiques de projet
Les mesures de base suivantes sont calculées pour l’ensemble du projet : – Groupes (G) :Nombre de groupes dans le projet.
– Packages (P) :Nombre de packages dans le projet. . Métriques liées aux dépendances
– Intra-Package méthode à la classe : dépendance d’une méthode à une autre classe du même package. Par exemple, le type d’un paramètre ou d’une variable locale.
– Extra-package méthode à la classe : dépendance d’une méthode à une autre classe dans un autre paquet. Par exemple, le type d’un paramètre ou d’une variable locale. – Class intra-package à la classe : la dépendance d’une classe à une autre classe du
même package. Par exemple, en étendant ou en mettant en œuvre des clauses. – Extra-package classe à la classe : la dépendance d’une classe à une autre classe dans
un autre paquet. Par exemple, en étendant ou en mettant en œuvre des clauses. – Intra-classe méthode à la méthode : la dépendance d’une méthode à une autre méthode
dans la même classe. Par exemple, un appel de méthode, y compris les constructeurs via la création d’objet.
– Intra-Package méthode à la méthode : la dépendance d’une méthode à une autre mé- thode dans une autre classe du même package. Par exemple, un appel de méthode, y compris les constructeurs via la création d’objet.
– Extra-package méthode à la méthode : la dépendance d’une méthode à une autre mé- thode dans une autre classe dans un autre paquet. Par exemple, un appel de méthode, y compris les constructeurs via la création d’objet.