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

173

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
MexicainHacker
la source
19
OUI c'est une "odeur de code" ... c2.com/cgi/wiki?LongMethodSmell
Dan Rosenstark
23
Lorsqu'il contient plus de 666 caractères, vous savez que vous avez un problème.
Thomas Eding
8
@yar dans votre exemple, l'opposé de "Méthode longue" est "Méthode courte" qui est considérée comme une bonne chose. Cela ne fait évidemment pas référence au nom de la méthode; il fait référence à des lignes de code (ou quelque chose de similaire). par exemple, f()c'est une fonction très courte, mais ce n'est certainement pas une bonne pratique ... et quelque chose que vous devriez dire à certains mathématiciens en programmation :)
sfussenegger
3
@sfussenegger, c'est vrai. Mais je parie sur une corrélation entre la longueur du nom de la méthode et la longueur de la méthode. f()peut-être pas une fonction géniale, mais ce $()type est comme une rockstar dans le monde de la méthode Javascript.
Dan Rosenstark
7
@yar, le lien que vous avez donné faisait référence à la longueur de la méthode en lignes, et non à la longueur du nom de la méthode .
Thorbjørn Ravn Andersen

Réponses:

398

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.

JaredPar
la source
65
Mathématiquement élégant.
Ricket
304
Ainsi, par exemple, boolean doesShorterNameExistThatEquallyConvaysTheBehaviorOfTheMethod(String s)devrait être remanié en boolean isTooLong(String s).
z5h le
6
Je ne suis pas tout à fait d'accord, car vous voulez non seulement transmettre le comportement, mais aussi garder la convention du projet et du langage. Donc, en Python, vous pourriez dire, eligible_items_cntmais en Java, vous dites généralement getEligibleItemsCount.
flybywire
17
@flybywire: Toute convention qui vous oblige à écrire des noms trop longs est d'un avantage douteux.
MAK
20
@MAK @ S.Lott et getLength()contre length()? J'aime vraiment regarder les autocomplétions après avoir tapé «get» ou «set» - donc je préfère la convection à la concision dans ce cas.
sfussenegger
202

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.

flybywire
la source
11
En outre, 5) va mettre getEligibleItems()et à getEligibleItemsCount()côté de l'autre dans des listes classées par ordre alphabétique (par exemple auto - complétion ou javadoc)
sfussenegger
4
Et comme il est généralement vrai, le nom plus court correspond à la règle du haïku.
sal
2
@mercator L'utilisation d'une convention standard comme getEligibleItems sur countEligibleItems réduit le risque d'ambiguïté dans l'instruction. Le moins ambigu sur ce que la méthode est censée faire augmente la lisibilité. Sans chercher plus loin dans la méthode, une méthode qui «compte» est moins claire que ce qu'une méthode qui «obtient» accomplit à long terme.
Bill
53
Je n'aime pas abbr comme Tx, Cnt, grphet ainsi de suite ... (BTW, Txest l' abréviation de « transmission » ou « émetteur »)
Meinersbur
14
Ouais, j'étais d'accord avec toi jusqu'à ce que tu décides d'utiliser "Tx".
Ponkadoodle
183

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

;-)

Mark Byers
la source
4
ouais, c'est trop long quand la JVM ne peut pas le gérer sans mo :)
Anurag
35
+1 pour LA réponse littérale.
sal
37
Techniquement, la spécification du langage Java n'a pas de limite supérieure pour la longueur de l'identifiant. Il s'agit d'une limitation de votre implémentation JVM. À votre santé!
uckelman
13
Le compilateur de Sun n'est apparemment pas conforme à la spécification. java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.8 dit: "Un identifiant est une séquence de longueur illimitée ..."
Michael Myers
6
La spécification JVM ne possède une limite supérieure, comme le message d'erreur signale. La représentation constante du pool des utf8 est limitée à 2 ^ 16 octets spécifiés ici . Les noms de classe et les noms de méthode doivent être stockés en tant que utf8 dans le pool de constantes.
thejoshwolfe
42

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.

Epaga
la source
5
+1 Je suis d'accord avec cela et c'est aussi ce que je fais, bien que les méthodes JUnit 4 ne soient plus nécessaires pour commencer test, cela ouvre également la possibilité d'utiliser should: comme dialogShouldCloseWhenTheRedButtonIsPressedTwice(). Ou vous pouvez appeler la classe de test DialogShould, puis la méthode closeWhenTheRedButtonIsPressedTwice(), afin de les lire ensemble: DialogShould.closeWhenTheRedButtonIsPressedTwice().
stivlo
Bien que je sois d'accord, je suggère également qu'une phrase trop longue peut suggérer un test qui en fait trop!
Brian Agnew
17

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.

S.Lott
la source
2
Pourrait également prendre une sorte de paramètre de transaction
willcodejavaforfood
3
Comme vous pouvez le voir d'après la réponse la plus performante ci-dessus, optez pour la simplicité de l'outback au lieu des conseils OO. +1
Dan Rosenstark
@yar Les gens ne se trompent jamais.
CurtainDog
12

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.

sal
la source
13
Les classes en obtiennent sept, les variables inférieures à cinq, sept pour le reste
James
8
"variables au plus cinq" (moins de cinq n'est pas précis)
Jason S
Des noms plus petits peuvent réduire la lisibilité du code.
Deniss M.
10

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.

flybywire
la source
20
On dirait que cette classe a été nommée par les personnes engagées par le Département de la redondance pour nommer des choses au Département de la redondance.
Michael Madsen
1
@MichaelMadsen: Est-ce vraiment redondant ou décrit-il un cadre imbriqué dans un autre cadre?
endolith
PEP-8 voudrait un mot avec ce nom de classe.
Mateen Ulhaq
9

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.

Geai
la source
+1 pour cette mauvaise réponse qui a souffert.
Dan Rosenstark
7

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();
Christoffer Hammarström
la source
6

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é.

Rex Kerr
la source
J'aime les règles comme ça. Tant que vous gardez à l'esprit que vous / votre équipe les avez constitués au hasard, tout va bien. D'un autre côté, je ne peux pas voter pour cela parce que «la recherche montrant» aurait en fait besoin d'un lien vers cette recherche, ou quelque chose à ce sujet ...
Dan Rosenstark
5

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.

Bill le lézard
la source
3

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"
Sreejesh
la source
13
Heureusement, il est juste des algues et pas un `` psycho ''
StingyJack
2

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 ()"

Jesse
la source
2

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.

Ben Gartner
la source
1

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

Dragon Kaz
la source
1

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.

Bill K
la source
1

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.

Brian T Hannan
la source
1

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.

vdboor
la source
Vous pouvez toujours argumenter l'inverse. Lorsqu'il est expliqué verbalement de quoi il s'agit, il est évidemment clair ce que la méthode fait autrement, cela pourrait semer la confusion et provoquer une mauvaise utilisation de la méthode.
Jonas Geiregat
0

Un nom d'identifiant est trop long lorsqu'il dépasse la longueur que votre compilateur Java peut gérer.

Uckelman
la source
3
Quoi?! Je ne vois pas pourquoi j'ai été critiqué pour cela. La question ne demandait pas une condition nécessaire, juste une condition suffisante!
uckelman
0

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 :)

HackerGil
la source
0

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)

Paul Grégoire
la source