Lorsque vous créez des règles définies par l'utilisateur à l'aide des modèles de règles, vous ne pouvez pas inclure d'explications ni d'exemples.
Si vous annulez des occurrences trouvées par les règles dans la catégorie Dépendances cycliques, ces occurrences sont supprimées de la vue de détail Révision de code. Elle ne doivent pas être supprimées, mais plutôt mises à l'état "Non résolu". Pour résoudre ce problème, sélectionnez les règles de la catégorie Dépendances cycliques et lancez une analyse de l'espace de travail.
En règle générale, vous pouvez résoudre un problème de code avec un correctif rapide d'analyse structurelle de deux manières : 1) en sélectionnant une classe existante vers laquelle vous transférez le code problématique ou 2) en créant une nouvelle classe pour y transférer le code problématique. Si vous optez pour la seconde méthode, une erreur empêche l'exécution d'un correctif rapide.
Pour résoudre ce problème, créez une classe avec d'appliquer le correctif rapide et sélectionnez la classe dans l'assistant de propagation des modifications de code.
La source contenue dans les packages suivants ne sera pas vérifiée par certaines des règles Pratiques recommandées dans J2EE :
1. com.ibm
2. COM.ibm
3. sun
4. sunw
5. java
6. javax
7. org.apache
8. com.sun
9. org.omg
10. org.ietf
11. org.w3c
12. org.xml
Dans la vue Révision de code, le numéro de ligne n'est pas toujours affiché pour certaines des occurrences détectées par les règles internes. Si vous cliquez deux fois sur l'occurrence, vous accédez au numéro de ligne approprié.
Un chemin de flux de données montre l'historique des dépendances des modifications de données ayant entraîné un incident mis en évidence par une recherche de règle. Les chemins de flux de données apparaissent dans la page Chemin. Les chemins de flux de données affichent parfois les structures de données internes des classes JSDK ou J2EE. Par exemple, au lieu d'un message indiquant qu'une variable de type java.lang.Vector a été modifiée, vous verrez un message spécifiant que la variable java.lang.Object[] a été modifiée. Il s'agit d'une zone interne à l'implémentation de java.lang.Vector et l'affichage de ces informations privées dans la page peut être déconcertant.
Dans la catégorie de règles Principes de conception, vous pouvez définir la longueur des règles de complexité. Par exemple, vous pouvez remplacer la règle "Evitez d'imbriquer plus de 1 class(es)" par "Evitez d'imbriquer plus de 3 class(es)." Pour que la règle fonctionne correctement, vous devez utiliser une longueur positive. Toutefois, les règles de complexité ne vérifient pas que vous avez bien affecté un nombre positif à la règle. Pour éviter cet incident, n'entrez pas de valeur non valide, telle qu'un zéro ou un nombre négatif.
Un problème de codage survient lorsque vous créez une règle à partir d'un modèle dont les paramètres contiennent des caractères ASCII non anglais. Cela se produit, par exemple, si un type ou une méthode contenant des caractères locaux est sélectionné. En raison de ce problème de codage, lorsque des règles créées avec ces propriétés et des caractères ASCII non anglais sont exécutées, une exception est générée.
La progression de la révision du code n'est pas correctement signalée pour les règles de l'analyse structurelle (la fenêtre de dialogue affiche en permanence une progression de 100 %). Vous devez attendre la fin de la révision du code.
Parfois, lorsque vous lancez la vérification du code, le bouton Démarrer/Arrêter affiche une icône représentant une combinaison de démarrer et arrêter.
Le correctif rapide de la règle "Evitez d'utiliser java.langString.compareTo () pour comparer des chaînes qui dépendent de l'environnement local" propose deux solutions pour résoudre l'incident ciblé par la règle. La solution recommandant d'<utiliser com.ibm.icu.text.Collator> est incorrecte. Vous devez <utiliser java.text.Collator>.
Si vous créez une règle à l'aide du modèle de règle J2EE "Appelez toujours [méthode A] après [méthode B]" et que [méthode B] correspond à un constructeur par défaut dans votre espace de travail, lorsque la règle est exécutée dans une vérification de code, aucune occurrence de règle n'est générée.
Si vous créez une règle pour une instance d'objet spécifique à partir du modèle de règle Pratiques recommandées dans J2EE : "Appelez toujours [méthode A] après [méthode B]", les occurrences de règle générées risquent d'être incorrectes dans le prochain cas pour lequel vous définissez une règle. Si vous sélectionnez des méthodes du pattern "Appelez toujours [méthode A] après [méthode B]" dans lequel, en code J2EE, les instances d'objet sur lesquelles vos méthodes ont un cycle de vie supérieur à celui du servlet analysé, les occurrences de règle détectées risquent d'être incorrectes. Prenons par exemple le cas du code suivant :
public void doGet( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException {
// Du code ici... final ServletOutputStream outStream = response.getOutputStream(); //... Aucune appel à response.flushBuffer après. }
Vous créez pour ce code la règle suivante : "Appelez toujours ServletResponse.flushBuffer() après ServletResponse.getOutputStream()". L'objet de réponse étant une instance dont le cycle de vie est supérieur à celui du servlet, l'analyse de la vérification du code peut poser des difficultés. Vous risquez de trouver dans d'autres servlets des occurrences qui ciblent l'incident du servlet actuel. Notez que la création de règles pour ces instances d'objet spécifiques est discutable.
Si vous créez une règle à l'aide du modèle de règle "Evitez de définir la méthode" et que vous sélectionnez une méthode avec un nom complet, seuls le nom de la méthode et les paramètres sont utilisés dans la vérification du code. Le modèle de règle s'intéresse surtout à la signature des méthodes ; les informations relatives au nom du package et de la classe ne lui sont d'aucune importance.
Lorsque vous créez une règle à partir d'un modèle de règle fourni, n'entrez pas le nom d'une méthode. Sélectionnez la méthode à l'aide du navigateur.
Lorsque vous configurez les données du serveur et qu'une fenêtre d'erreurs signalées apparaît, fermer la page correspondant au fichier .java (code de page), puis réessayez de configurer les données.
Sous Linux™, dans la page Préférences, vous ne pourrez peut-être pas voir toutes les catégories de règle et les détails sur les règles si la vérification de code sélectionnée contient une quantité importante de règles. Pour remédier à cela, sélectionnez Révision de code rapide dans la page Préférences, fermez la page Préférences, puis ouvrez-la à nouveau. Vous pouvez alors sélectionner une vérification de code et cette dernière apparaît correctement.
Retour au fichier Readme principal