Erreurs typiques dans le code Java.

Ce matériel contient les erreurs les plus typiques que j'ai vues dans le code Java des personnes travaillant avec moi. L'analyse statique (nous utilisons qulice ), pour des raisons évidentes, ne peut pas détecter toutes ces erreurs, c'est pourquoi j'ai décidé de les lister ici. Toutes ces erreurs sont liées à la programmation orientée objet en général et à Java en particulier.

Noms de classe

Votre classe doit être une abstraction d'un objet réel sans " validateurs " , " contrôleurs " , " gestionnaires " , etc. Si le nom de votre classe se termine par "-er", c'est une mauvaise conception. Et bien sûr, les classes d'assistance anti-modèle comme StringUtils , FileUtils et IOUtils d'Apache sont d'excellents exemples de modèles de conception épouvantables. N'ajoutez jamais de suffixes ou de préfixes pour différencier les interfaces et les classes. Par exemple, tous ces noms sont terribles : IRecord , IfaceEmployee ou RecordInterface . Généralement, le nom de l'interface est le nom de l'objet réel, tandis que le nom de la classe doit expliquer les détails de l'implémentation. Si rien de spécifique ne peut être dit sur l'implémentation, les noms " Default ", " Simple " ou quelque chose de similaire feront l'affaire. Par exemple: class SimpleUser implements User {}; class DefaultRecord implements Record {}; class Suffixed implements Name {}; class Validated implements Content {};

Noms des méthodes

Les méthodes peuvent renvoyer « quelque chose » ou renvoyer « void ». Si une méthode renvoie quelque chose, son nom doit expliquer ce qui sera renvoyé. Par exemple (n'utilisez pas le préfixe " get ") : boolean isValid(String name); String content(); int ageOf(File file); Si " void " est renvoyé, le nom doit clarifier ce que fait la méthode. Par exemple : void save(File file); void process(Work work); void append(File file, String line); il n'y a qu'une seule exception à cette règle : les méthodes de test JUnit . Ils sont décrits ci-dessous.

Noms des méthodes de test

Les noms de méthodes dans les tests JUnit doivent être construits sous forme de phrase anglaise sans espaces. C'est plus facile à expliquer avec un exemple : il est /** * HttpRequest can return its content in Unicode. * @throws Exception If test fails */ public void returnsItsContentInUnicode() throws Exception { } important de commencer la première phrase de votre JavaDoc par le nom de la classe que vous testez suivi de « can ». Ainsi, la première phrase doit toujours ressembler à l’expression «  quelqu’un peut faire quelque chose ». Le nom de la méthode indiquera la même chose, mais sans le sujet du test. Si je l'ajoute au début du nom de la méthode, j'obtiens une phrase anglaise complète, comme dans l'exemple ci-dessus : « HttpRequest renvoie son contenu en unicode ». Veuillez noter que le nom de la méthode de test ne commence pas par « can ». Seuls les commentaires JavaDoc commencent par « can ». De plus, les noms de méthodes ne doivent pas commencer par un verbe ( Du traducteur : apparemment, l'auteur veut dire le mode impératif du verbe ). Il est de bonne pratique d'indiquer qu'une exception est levée lors de la déclaration d'une méthode de test.

Noms des variables

Évitez les noms de variables composés tels que timeOfDay , firstItem ou httpRequest . Je veux dire à la fois les variables de classe et les variables de méthode. Le nom de la variable doit être suffisamment long pour éviter toute ambiguïté quant à sa portée, mais pas trop long si possible. Le nom doit être un nom singulier ou pluriel. Par exemple : il peut parfois y avoir des collisions entre les paramètres du constructeur et les champs de classe si le constructeur stocke les données d'entrée dans l'objet créé. Dans ce cas, je recommande de créer une abréviation en supprimant les voyelles. Exemple : Dans la plupart des cas, le meilleur nom de variable sera le nom de la classe correspondante. Mettez-le simplement en majuscule et tout ira bien : cependant, ne faites jamais la même chose pour les types primitifs comme ou . Vous pouvez également utiliser des adjectifs lorsqu'il existe plusieurs variables ayant des caractéristiques différentes. Par exemple: List names; void sendThroughProxy(File file, Protocol proto); private File content; public HttpRequest request; public class Message { private String recipient; public Message(String rcpt) { this.recipient = rcpt; } } File file; User user; Branch branch; Integer number String string String contact(String left, String right);

Constructeurs

Sans exception, il ne devrait y avoir qu'un seul constructeur qui stocke les données dans des variables d'objet. Tous les autres constructeurs doivent appeler celui-ci avec des paramètres différents : public class Server { private String address; public Server(String uri) { this.address = uri; } public Server(URI uri) { this(uri.toString()); } }

Variables ponctuelles

Évitez à tout prix les variables ponctuelles. Par « jetable », j'entends des variables qui ne sont utilisées qu'une seule fois. Comme dans cet exemple : String name = "data.txt"; return new File(name); une variable n'est utilisée qu'une seule fois, et le code peut être simplifié comme suit : return new File("data.txt"); Parfois, dans de très rares cas - principalement en raison d'un meilleur formatage - des variables uniques peuvent être utilisées. Cependant, essayez d'éviter de telles situations.

Des exceptions.

Bien entendu, vous ne devez jamais « avaler » les exceptions ; elles doivent être lancées le plus haut possible. Les exceptions des méthodes privées doivent être gérées en externe. N’utilisez jamais d’exceptions pour contrôler le flux. Le code dans l'exemple est incorrect : int size; try { size = this.fileSize(); } catch (IOException ex) { size = 0; } sérieusement, que se passe-t-il si l'IOException indique "le disque est plein", supposerez-vous que la taille du fichier est nulle et continuerez ?

Échancrure.

Pour l'indentation, la règle générale est que la parenthèse doit soit terminer la ligne, soit se fermer sur la même ligne (la règle inverse s'applique pour la parenthèse fermante). Dans l'exemple ci-dessous, le code est incorrect car la première parenthèse n'est pas fermée sur la même ligne et des caractères la suivent. La deuxième parenthèse a le même problème car elle est précédée de caractères et il n'y a pas de parenthèse ouvrante sur la ligne actuelle. final File file = new File(directory, "file.txt"); Une indentation correcte devrait ressembler à ceci : StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join( Arrays.asList("a", "b") ) ), "separator" ); La deuxième règle importante en matière d'indentation est que vous devez en placer autant que possible sur une seule ligne, dans un rayon de 80 caractères. L'exemple ci-dessus n'est pas valide car il peut être compressé : StringUtils.join( Arrays.asList( "first line", "second line", StringUtils.join(Arrays.asList("a", "b")) ), "separator" );

Constantes redondantes.

Les constantes de classe doivent être utilisées lorsque vous souhaitez partager l'accès aux informations entre les méthodes de classe, et ces informations sont une caractéristique ( ! ) de votre classe. N'utilisez pas de constantes pour remplacer des chaînes ou des littéraux numériques - très mauvaise pratique, cela conduit à une pollution du code. Les constantes (comme les autres objets POO) doivent avoir une signification dans le monde réel. Quelle est la signification de ces constantes dans le monde réel : class Document { private static final String D_LETTER = "D"; // bad practice private static final String EXTENSION = ".doc"; // good practice } Une autre erreur courante consiste à utiliser des constantes dans les tests unitaires pour éviter de dupliquer des chaînes/littéraux numériques dans les méthodes de test. Ne faites pas cela! Chaque méthode de test doit fonctionner sur son propre ensemble de valeurs d'entrée. Utilisez de nouveaux textes et chiffres dans chaque nouvelle méthode de test. Les tests sont indépendants. Alors pourquoi devraient-ils partager les mêmes constantes d’entrée ?

Tester le couplage des données.

Voici un exemple de hooking dans une méthode de test : User user = new User("Jeff"); // maybe some other code here MatcherAssert.assertThat(user.name(), Matchers.equalTo("Jeff")); Dans la dernière ligne, nous concaténons « Jeff » avec la même chaîne littérale spécifiée dans la première ligne. Si, quelques mois plus tard, quelqu'un souhaite modifier la valeur de la troisième ligne, il devra passer plus de temps à chercher où d'autre « Jeff » est utilisé dans cette méthode. Pour éviter cet accrochage de données, vous devez introduire une variable.