Quand un Java est-il trop long?
Au cours des dernières semaines, j'ai vu des gars utiliser des noms très longs pour une méthode ou une classe (50 caractères), c'est généralement sous l'hypothèse qu'il améliore la lisibilité, mon avis est qu'un nom long comme celui-ci est un indicateur que nous sommes essayer de faire beaucoup ou trop dans une classe de méthode si nous avons besoin d'un nom aussi long, mais je voulais savoir ce que vous en pensez.
Un exemple est:
getNumberOfSkinCareEligibleItemsWithinTransaction
Un nom en Java ou dans tout autre langage est trop long lorsqu'il existe un nom plus court qui transmet également le comportement de la méthode.
Quelques techniques pour réduire la longueur des noms de méthode:
Si tout votre programme, classe ou module concerne les "articles de soins de la peau", vous pouvez abandonner les soins de la peau. Par exemple, si votre classe s'appelle
SkinCareUtils, cela vous amène àgetNumberOfEligibleItemsWithinTransactionVous pouvez changer dans en dans ,
getNumberOfEligibleItemsInTransactionVous pouvez changer Transaction en Tx, ce qui vous amène à
getNumberOfEligibleItemsInTx.Ou si la méthode accepte un paramètre de type
Transaction, vous pouvez supprimer complètement l'InTx:getNumberOfEligibleItemsVous changez numberOf par count:
getEligibleItemsCount
Maintenant, c'est très raisonnable. Et il est 60% plus court.
Juste pour un changement, une réponse non subjective: 65536 caractères.
A.Java:1: la représentation UTF8 pour la chaîne "xxxxxxxxxxxxxxxxxxxx ..." est trop longue pour le pool constant
;-)
Je suis d'accord avec tout le monde: les noms de méthode ne devraient pas être trop longs. Je veux cependant ajouter une exception:
Cependant, les noms des méthodes de test JUnit peuvent être longs et doivent ressembler à des phrases.
Pourquoi?
- Parce qu'ils ne sont pas appelés dans un autre code.
- Parce qu'ils sont utilisés comme noms de test.
- Parce qu'ils peuvent alors être écrits sous forme de phrases décrivant les exigences. (Par exemple, en utilisant AgileDox )
Exemple:
@Test
public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() {
...
}
Voir " Behavior Driven Design " pour plus d'informations sur cette idée.
Le contexte "... WithinTransaction" devrait être évident. C'est à cela que sert l'orientation objet.
La méthode fait partie d'une classe. Si la classe ne signifie pas "Transaction" - et si cela ne vous évite pas de devoir dire "WithinTransaction" tout le temps, alors vous avez des problèmes.
J'ai tendance à utiliser la règle haïk pour les noms:
Seven syllable class names
five for variables
seven for method and other names
Ce sont des règles de base pour les noms max. Je ne viole cela que lorsqu'il améliore la lisibilité. Quelque chose comme recalculateMortgageInterest (currentRate, quoteSet ...) est meilleur que recalculateMortgageInterestRate ou recalculateMortgageInterestRateFromSet car le fait qu'il implique des taux et un ensemble de devis devrait être assez clair par rapport aux documents intégrés comme javadoc ou l'équivalent .NET.
REMARQUE: Pas un vrai haïku, car il s'agit de 7-5-7 plutôt que de 5-7-5. Mais je préfère toujours l'appeler haïku.
Java a une culture qui encourage les noms longs, peut-être parce que les IDE sont livrés avec une bonne autocomplétion.
Ce site indique que le nom de classe le plus long dans le JRE est InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState qui fait 92 caractères.
Quant au nom de méthode le plus long, j'ai trouvé celui-ci supportsDataDefinitionAndDataManipulationTransactions, qui est de 52 caractères.
N'utilisez jamais un long mot quand un diminutif fera l'affaire.
Je ne pense pas que votre thèse de "la longueur du nom de la méthode soit proportionnelle à la longueur de la méthode" retienne vraiment.
Prenons l'exemple que vous donnez: "getNumberOfSkinCareEligibleItemsWithinTransaction". Cela me semble que cela ne fait qu'une chose: il compte le nombre d'articles dans une transaction qui tombent dans une certaine catégorie. Bien sûr, je ne peux pas juger sans voir le code réel de la méthode, mais cela me semble être une bonne méthode.
D'un autre côté, j'ai vu beaucoup de méthodes avec des noms très courts et concis qui font beaucoup de travail, comme "processSale" ou le très populaire "doStuff".
Je pense qu'il serait difficile de donner une règle stricte sur la longueur du nom de la méthode, mais l'objectif devrait être: assez long pour transmettre ce que fait la fonction, assez court pour être lisible. Dans cet exemple, je pense que "getSkinCareCount" aurait probablement suffi. La question est de savoir ce que vous devez distinguer. Si vous avez une fonction qui compte les articles éligibles aux soins de la peau dans les transactions et une autre qui compte les articles éligibles aux soins de la peau dans autre chose, alors "withinTransactions" ajoute de la valeur. Mais si cela ne veut rien dire de parler de ces éléments en dehors d'une transaction, il est inutile d'encombrer le nom avec des informations aussi superflues.
Deuxièmement, je pense qu'il est extrêmement irréaliste de supposer qu'un nom de n'importe quelle longueur gérable vous dira exactement ce que fait la fonction dans tous les cas sauf les plus triviaux. Un objectif réaliste est de faire un nom qui donne un indice au lecteur, et qui peut être rappelé plus tard. Par exemple, si j'essaie de trouver le code qui calcule la quantité d'antimatière que nous devons consommer pour atteindre la vitesse de distorsion, si je regarde les noms des fonctions et que je vois "calibrateTransporter", "firePhasers" et "calcAntimatterBurn", il est assez clair que les deux premiers ne le sont pas mais le troisième pourrait l'être. Si je vérifie et trouve que c'est bien celui que je recherche, il sera facile de se souvenir que lorsque je reviendrai demain pour travailler sur ce problème encore. Il est assez bien.
Trois, les noms longs similaires sont plus déroutants que les noms courts. Si j'ai deux fonctions appelées "calcSalesmanPay" et "calcGeekPay", je peux faire une bonne estimation qui est celle qui en un coup d'œil. Mais s'ils sont appelés "CalculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation" et "CalculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation", je dois étudier les noms pour voir lequel est lequel. Les informations supplémentaires dans le nom sont probablement contre-productives dans de tels cas. Cela transforme une réflexion d'une demi-seconde en une réflexion de 30 secondes.
Concevez votre interface comme vous le souhaitez et faites correspondre l'implémentation.
Par exemple, j'écrirais peut-être cela comme
getTransaction().getItems(SKIN_CARE).getEligible().size()
ou avec Java 8 flux:
getTransaction().getItems().stream()
.filter(item -> item.getType() == SKIN_CARE)
.filter(item -> item.isEligible())
.count();
Ma règle est la suivante: si un nom est si long qu'il doit apparaître sur sa propre ligne, alors il est trop long. (En pratique, cela signifie que je dépasse rarement 20 caractères.)
Ceci est basé sur des recherches montrant que le nombre de lignes verticales visibles de code est en corrélation positive avec la vitesse/efficacité du codage. Si les noms de classe/méthode commencent à nuire considérablement à cela, ils sont trop longs.
Ajoutez un commentaire où la méthode/classe est déclarée et laissez le IDE vous y emmener si vous voulez une longue description de ce à quoi il sert.
La longueur de la méthode elle-même est probablement un meilleur indicateur de savoir si elle en fait trop, et même cela ne vous donne qu'une idée approximative. Vous devez vous efforcer d'être concis, mais la description est plus importante. Si vous ne pouvez pas transmettre la même signification dans un nom plus court, le nom lui-même est probablement correct.
Lorsque vous allez écrire un nom de méthode la prochaine fois, pensez à la citation ci-dessous
"The man who is going to maintain your code is a phyco who knows where you stay"
n nom de variable est trop long quand un nom plus court permettra une meilleure lisibilité du code sur tout le programme ou les parties importantes du programme.
Si un nom plus long vous permet de transmettre plus d'informations sur une valeur. Cependant, si un nom est trop long, il encombrera le code et réduira la capacité à comprendre le reste du code. Cela se produit généralement en provoquant des sauts de ligne et en poussant d'autres lignes de code hors de la page.
L'astuce consiste à déterminer lequel offrira une meilleure lisibilité. Si la variable est utilisée souvent ou plusieurs fois dans un court espace, il peut être préférable de lui donner un nom court et d'utiliser un commentaire clarifier. Le lecteur peut se référer facilement au commentaire. Si la variable est souvent utilisée tout au long du programme, souvent en tant que paramètre ou dans d'autres opérations compliquées, il peut être préférable de réduire le nom ou d'utiliser des acronymes pour rappeler au lecteur. Ils peuvent toujours référencer un commentaire par la déclaration de variable s'ils oublient la signification.
Ce n'est pas un compromis facile à faire, car vous devez considérer ce que le lecteur de code est susceptible d'essayer de comprendre, et également prendre en compte la façon dont le code va changer et croître avec le temps. C'est pourquoi nommer les choses est difficile.
La lisibilité est la raison pour laquelle il est acceptable d'utiliser i comme compteur de boucles au lieu de DescriptiveLoopCounterName. Étant donné qu'il s'agit de l'utilisation la plus courante d'une variable, vous pouvez dépenser le moins d'espace d'écran pour expliquer pourquoi elle existe. Le nom plus long va juste perdre du temps en rendant plus difficile la compréhension de la façon dont vous testez la condition de boucle ou l'indexation dans un tableau.
À l'autre extrémité du spectre, si une fonction ou une variable est rarement utilisée comme dans une opération complexe, comme être passée à un appel de fonction multi-paramètres, vous pouvez vous permettre de lui donner un nom trop descriptif.
Ce nom de méthode est définitivement trop long. Mon esprit a tendance à errer lorsque je lis des noms de méthode de cette taille. C'est comme lire une phrase sans espaces.
Personnellement, je préfère le moins de mots possible dans les méthodes. Vous êtes aidé si le package et le nom de classe peuvent transmettre un sens. Si la responsabilité de la classe est très concise, il n'y a pas besoin d'un nom de méthode géant. Je suis curieux de savoir pourquoi "WithinTransaction" là-bas.
"getNumberOfSkinCareEligibleItemsWithinTransaction" pourrait devenir:
com.mycompany.app.product.SkinCareQuery.getNumEligibleItems ();
Ensuite, lorsqu'elle est utilisée, la méthode pourrait ressembler à "query.getNumEligibleItems ()"
C'est trop long lorsque le nom de la méthode passe sur une autre ligne et l'appel à la méthode est la seule chose sur la ligne et commence assez près de la marge. Vous devez prendre en compte la taille moyenne de l'écran des personnes qui l'utiliseront.
Mais! Si le nom semble trop long, il est probablement trop long. Le moyen de le contourner est d'écrire votre code de telle manière que vous vous trouviez dans un contexte et que le nom soit court mais dupliqué dans d'autres contextes. C'est comme quand vous pouvez dire "elle" ou "il" en anglais au lieu du nom complet de quelqu'un.
Comme avec tout autre langage: lorsqu'il ne décrit plus l'action unique que la fonction effectue.
Je dirais utiliser une combinaison des bonnes réponses et être raisonnable.
Décrivez de manière complète, claire et lisible ce que fait la méthode.
Si le nom de la méthode semble trop long - refactorisez la méthode pour en faire moins.
C'est trop long quand cela explique trop verbalement de quoi il s'agit.
Par exemple, ces noms sont fonctionnellement équivalents.
en Java: Java.sql.SQLIntegrityConstraintViolationException
en Python/Django: Django.db.IntegrityError
Demandez-vous, dans un package SQL/db, combien d'autres types d'erreurs d'intégrité pouvez-vous trouver? ;) Par conséquent db.IntegrityError est suffisant.
Un nom d'identifiant est trop long lorsqu'il dépasse la longueur que votre compilateur Java peut gérer.
Il y a deux façons ou points de vue ici: Le premier est que la longueur du nom de la méthode n'a pas d'importance, tant qu'elle est aussi descriptive que possible pour décrire ce que fait la méthode (règle de base des meilleures pratiques Java). D'un autre côté, je suis d'accord avec le message flybywire. Nous devons utiliser notre intelligence pour essayer de réduire autant que possible le nom de la méthode, mais sans réduire sa descriptivité. La description est plus importante :)
Un nom est trop long s'il:
- Prend plus d'une seconde pour lire
- Prend plus RAM que vous allouez pour votre JVM
- Est quelque chose d'absurdement nommé
- Si un nom plus court est parfaitement logique
- S'il s'enroule dans votre IDE
Honnêtement, le nom n'a besoin que de communiquer son objectif aux développeurs qui l'utiliseront comme méthode API publique ou devront maintenir le code lorsque vous quitterez. N'oubliez pas KISS (gardez les choses stupides)