Quand un nom de méthode Java est-il trop long? [fermé]

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 en partant du principe que cela améliore la lisibilité, mon avis est qu'un nom long comme celui-ci est un indicateur que nous sommes essayer d'en faire beaucoup ou trop dans une classe de méthodes 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 exprime également le comportement de la méthode.

Quelques techniques pour réduire la longueur des noms de méthodes:

1. Si l'ensemble de votre programme, classe ou module concerne les «articles de soin de la peau», vous pouvez abandonner les soins de la peau. Par exemple, si votre classe est appelée SkinCareUtils, cela vous amène àgetNumberOfEligibleItemsWithinTransaction

2. Vous pouvez changer au sein de dans ,getNumberOfEligibleItemsInTransaction

3. Vous pouvez changer Transaction en Tx, ce qui vous amène à getNumberOfEligibleItemsInTx.

4. Ou si la méthode accepte un paramètre de type, Transactionvous pouvez supprimer complètement l'InTx:getNumberOfEligibleItems

5. Vous modifiez le nombre par décompte: getEligibleItemsCount

Maintenant c'est très raisonnable. Et c'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 de constantes

;-)

Je suis d'accord avec tout le monde: les noms de méthodes ne doivent pas être trop longs. Je veux cependant ajouter une exception:

Les noms des méthodes de test JUnit, cependant, 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 « Conception guidée par le comportement » pour plus d'informations sur cette idée.

Le contexte "... WithinTransaction" doit être évident. C'est ce qu'est l'orientation objet.

La méthode fait partie d'une classe. Si la classe ne signifie pas «Transaction» - et si elle ne vous évite pas de dire «WithinTransaction» tout le temps, alors vous avez des problèmes.

J'ai tendance à utiliser la règle du haïku pour les noms:

 Seven syllable class names 
 five for variables
 seven for method and other names

Ce sont des règles empiriques pour les noms max. Je ne viole cela que lorsque cela améliore la lisibilité. Quelque chose comme recalculateMortgageInterest (currentRate, quoteSet ...) est mieux que recalculateMortgageInterestRate ou recalculateMortgageInterestRateFromSet car le fait qu'il implique des taux et un ensemble de citations devrait être assez clair à partir des documents intégrés comme javadoc ou l'équivalent .NET.

REMARQUE: ce n'est pas un vrai haïku, car c'est 7-5-7 plutôt que 5-7-5. Mais je préfère toujours l'appeler haïku.

Java a pour culture d'encourager 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 du JRE estInternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState est de 92 caractères.

En ce qui concerne le nom de méthode le plus long, j'ai trouvé celui-ci supportsDataDefinitionAndDataManipulationTransactions, qui contient 52 caractères.

N'utilisez jamais un mot long quand un minuscule fera l'affaire.

Je ne pense pas que votre thèse sur «la longueur du nom de la méthode est proportionnelle à la longueur de la méthode» tient vraiment la route.

Prenons l'exemple que vous donnez: "getNumberOfSkinCareEligibleItemsWithinTransaction". Cela me semble que cela ne fait qu'une chose: cela compte le nombre d'articles dans une transaction qui entrent 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 toujours populaire "doStuff".

Je pense qu'il serait difficile de donner une règle absolue 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 été suffisant. 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 tels éléments en dehors d'une transaction, alors 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 créer un nom qui donne un indice au lecteur et qui puisse ê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 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 s'en souvenir quand je reviendrai demain pour travailler encore sur ce problème. Il est assez bien.

Trois 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 laquelle 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 demi-seconde de réflexion en 30 secondes de réflexion.

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 les flux Java 8:

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 une ligne propre, alors il est trop long. (En pratique, cela signifie que je suis rarement au-dessus de 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 classes / méthodes commencent à nuire considérablement, ils sont trop longs.

Ajoutez un commentaire où la méthode / classe est déclarée et laissez l'EDI vous y emmener si vous voulez une longue description de son utilité.

La longueur de la méthode elle-même est probablement un meilleur indicateur pour savoir si elle en fait trop, et même cela ne vous donne qu'une idée approximative. Vous devez rechercher la concision, 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 simplement à la citation ci-dessous

"The man who is going to maintain your code is a phyco who knows where you stay"

Ce nom de méthode est définitivement trop long. Mon esprit a tendance à s'égarer lorsque je lis des noms de méthodes d'une telle 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 la classe peuvent donner 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, lors de son utilisation, la méthode pourrait ressembler à "query.getNumEligibleItems ()"

Un nom de variable est trop long lorsqu'un nom plus court permettra une meilleure lisibilité du code sur l'ensemble du programme ou sur 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 retours à la ligne et en poussant d'autres lignes de code hors de la page.

L'astuce consiste à déterminer ce qui offrira une meilleure lisibilité. Si la variable est utilisée souvent ou plusieurs fois dans un espace court, il peut être préférable de lui donner un nom court et d'utiliser un commentaire clarifier. Le lecteur peut facilement se référer 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 en 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 aussi prendre en compte la façon dont le code va changer et évoluer avec le temps. C'est pourquoi il est difficile de nommer les choses.

La lisibilité est la raison pour laquelle il est acceptable d'utiliser i comme compteur de boucle au lieu de DescriptiveLoopCounterName. Comme il s'agit de l'utilisation la plus courante d'une variable, vous pouvez consacrer le moins d'espace à l'écran à expliquer pourquoi elle existe. Le nom plus long va simplement perdre du temps en rendant plus difficile la compréhension de la manière 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.

Comme pour tout autre langage: lorsqu'il ne décrit plus l'action unique que la fonction effectue.

Je dirais d'utiliser une combinaison des bonnes réponses et d'ê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, modifiez la méthode pour en faire moins.

C'est trop long lorsque le nom de la méthode s'enroule sur une autre ligne et que l'appel à la méthode est la seule chose sur la ligne et commence assez près de la marge. Il faut tenir compte de la taille moyenne de l'écran des personnes qui l'utiliseront.

Mais! Si le nom semble trop long, il est probablement trop long. La façon de le contourner est d'écrire votre code de telle manière que vous soyez 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.

C'est trop long quand il 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 générer? ;) C'est db.IntegrityErrordonc 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: La première est que la longueur du nom de la méthode n'a pas vraiment d'importance, du moment qu'il est aussi descriptif que possible pour décrire ce que fait la méthode (règle de base des meilleures pratiques Java). En revanche, je suis d'accord avec le poste flybywire. Nous devrions utiliser notre intelligence pour essayer de réduire autant que possible le nom de la méthode, mais sans réduire son caractère descriptif. La description est plus importante :)

Un nom est trop long s'il:

• Prend plus d'une seconde à lire
• Prend plus de RAM que vous n'en allouez pour votre JVM
• Est-ce que quelque chose s'appelle absurdement
• Si un nom plus court est parfaitement logique
• S'il s'enroule dans votre IDE

Honnêtement, le nom n'a besoin que de transmettre son objectif aux développeurs qui l'utiliseront comme méthode d'API publique ou devront maintenir le code lorsque vous quitterez. Souviens-toi juste de KISS (reste simple stupide)