Lorsque Java est le nom de la méthode trop longue?
Dans les dernières semaines, j'ai vu des gars en utilisant des noms longs pour une Méthode ou une Classe (50 caractères), c'est généralement sous la prémisse qu'il améliore la lisibilité, mon avis est qu'un nom long comme c'est un indicateur que nous essayons de faire beaucoup ou trop dans une méthode de classe, si nous avons besoin d'un tel nom long, mais je voulais savoir ce que vous pensez de cela.
En est un Exemple:
getNumberOfSkinCareEligibleItemsWithinTransaction
- OUI c'est une "odeur de code"... c2.com/cgi/wiki?LongMethodSmell
- Quand il est > 666 caractères, alors vous savez que vous avez un problème.
- dans votre exemple, le contraire de "Méthode" est "de Courte durée", qui est considéré comme une bonne chose. Il est donc évidemment pas référence à la méthode nom; c'est en se référant à des lignes de code (ou soemthing similaire). par exemple,
f()
est très court, mais c'est certainement pas une bonne pratique ... et quelque chose que vous devriez dire à certains de programmation mathématiciens là-bas 🙂 - c'est vrai. Mais je parie sur une corrélation entre la méthode de la longueur du nom et de la méthode de la longueur.
f()
ne peut pas être une fonction très utile, mais que$()
gars, c'est comme une rockstar dans la méthode Javascript monde. - le lien que tu as donné visé à la longueur de la méthode dans les lignes, pas la longueur du nom de la méthode.
- bon point 🙂 mais les pauvres gars qui n'ont décent auto-complétion, ni d'un compilateur de captures (la plupart) des fautes de frappe. Pour moi, le
$()
est comme le feu: il n'est pas si impressionnant, si vous avez les bons outils 😀 - f() serait bien si vous jouez à codegolf ou de codage dans golfscript
- Eh bien, en regardant que j'ai une certaine idée de la méthode est, et il semble que ça ne fait qu'une seule chose. Il améliore la lisibilité. Writability, sur l'autre main, peut-être pas.
- Ravn Andersen, je sais, mais l'homme a été rapide je. Mais comme je l'ai dit après, je vais parier sur une corrélation entre la longueur du nom et la durée de la fonction. Sauf si c'est une relation inverse, à l'instar de "processus".
- Cet article est un beau lire et c'est un peu liée à votre question.
- Si vous avez la complétion de code disponible dans votre ide, je préfère le nom de l'être en tant qu'il doit être pour plus de clarté. De cette façon, lorsque vous êtes présenté avec une liste de méthodes pour appeler... vous pouvez le comprendre par la numérisation tout les noms.
- Puis de nouveau, la plupart du code de golf entrées ne passerait pas la moyenne de votre examen du code.
- ouais j'imagine que le WTFs/min taux plutôt élevé
- Si ce code traite exclusivement avec des produits de Soin, vous pouvez omettre cette partie du nom de la fonction. Si non, tous les soins de la peau liées à des fonctions qui doivent être les méthodes de la classe (encore alowing vous omettez "Soin")
- Vous pouvez raccourcir votre méthode noms autant que vous voulez, mais
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter.q()
sera toujours absurde. - Je ne suis pas d'accord avec l'odeur de code idée. Le lien est
old
et il parle aussi d'If one is doing procedural-style code
.. - ouais, en 2010, que le lien a été fait différent 😉
- Je ne pense pas que je vais jamais comprendre. Avoir semblent quelques belles questions fermées à cause de l'opinion "base" alors qu'ils ne l'étaient pas, cette question reste encore ouverte, lorsque l'OP a demandé en particulier que les "opinions". Pourquoi est-ce le cas?
- Puis-je suggérer le nom n'est pas la longueur n'est pas si important, mais plutôt la quantité de verbes et les noms??
Vous devez vous connecter pour publier un commentaire.
Un nom en Java, ou en toute autre langue, est trop long quand un nom plus court existe également traduit le comportement de la méthode.
boolean doesShorterNameExistThatEquallyConvaysTheBehaviorOfTheMethod(String s)
doit être reconstruit pourboolean isTooLong(String s)
.eligible_items_cnt
mais en Java vous l'habitude de diregetEligibleItemsCount
.getLength()
vslength()
? J'aime vraiment regarder autocompletions après avoir tapé 'get' ou 'set' - donc je préfère convetion plus de concision dans ce cas.Certaines techniques de réduction de la longueur des noms de méthode:
Si l'ensemble de votre programme, ou d'une classe ou d'un module est au sujet des soins de la peau d'articles que vous pouvez déposer des soins de la peau. Par exemple, si votre classe est appelée
SkinCareUtils
,qui vous amène à
getNumberOfEligibleItemsWithinTransaction
Vous pouvez modifier dans à dans,
getNumberOfEligibleItemsInTransaction
Vous pouvez changer Transaction Tx, ce qui vous obtient à
getNumberOfEligibleItemsInTx
.Ou si la méthode accepte un paramètre de type
Transaction
, vous pouvez laisser les InTx tout à fait:getNumberOfEligibleItems
Vous changer numberOf par le comte:
getEligibleItemsCount
Maintenant c'est très raisonnable. Et c'est 60% plus courte.
getEligibleItems()
etgetEligibleItemsCount()
uns à côté des autres dans l'ordre alphabétique des listes ordonnées (par exemple, l'auto-complétion ou javadoc)countEligibleItems
?get
,set
ouis
, ce qui est exactement le genre de chose qui conduit à des noms longs comme ça.Tx
,Cnt
,grph
, et ainsi de suite... (btw,Tx
est l'abréviation de "Transmission" ou "l'Émetteur")countEligibleItems
7.countEligible
8.eligible
- puisqu'il revientint
vous doit deviner que cela signifie comte 😉 9.el
Juste pour un changement, un non-subjective réponse: 65536 caractères.
😉
Je suis d'accord avec tout le monde: les noms de méthode ne devrait pas être trop long. Je veux ajouter une exception cependant:
Les noms de test JUnit méthodes, cependant, peut être long et doit ressembler à peine.
Pourquoi?
Exemple:
Voir "Comportement Axé Sur La Conception" pour plus d'info sur cette idée.
test
plus, cela ouvre également la possibilité d'utilisershould
: commedialogShouldCloseWhenTheRedButtonIsPressedTwice()
. Ou vous pouvez appeler la classe de testDialogShould
, puis la méthodecloseWhenTheRedButtonIsPressedTwice()
, de sorte à les lire ensemble:DialogShould.closeWhenTheRedButtonIsPressedTwice()
.Contexte "...WithinTransaction" devrait être évident. C'est ce que l'orientation de l'objet est tout au sujet.
La méthode fait partie d'une classe. Si la classe ne veut pas dire "Transaction" -- et si il ne vous économiser de dire "WithinTransaction" tout le temps, alors vous avez des problèmes.
J'ai tendance à utiliser le haïku règle pour noms:
Ce sont les règles du pouce pour les noms de max. Je ne respecte pas ce que quand il améliore la lisibilité. Quelque chose comme recalculateMortgageInterest(currentRate, quoteSet...) est mieux que recalculateMortgageInterestRate ou recalculateMortgageInterestRateFromset depuis le fait qu'il comporte les tarifs et un ensemble de citations devraient être assez clair de l'embedded docs comme javadoc ou la .NET équivalent.
NOTE: Pas un véritable haïku, comme il est 7-5-7 plutôt que de 5-7-5. Mais je préfère encore l'appeler haïku.
Java a une culture de encourageants des noms longs, peut-être parce que les IDEs de venir avec une bonne auto-complétion.
Ce site dit que le plus long nom de la classe dans le JRE est
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
qui est de 92 caractères de long.Comme pour le plus long nom de la méthode que j'ai trouvé cette
supportsDataDefinitionAndDataManipulationTransactions
, qui est de 52 caractères.N'utilisez jamais un mot long quand un diminutif on va faire.
Je ne pense pas que votre thèse de la "longueur du nom de la méthode est proportionnelle à la longueur de la méthode" vraiment retient l'eau.
Prendre l'exemple que vous donnez: "getNumberOfSkinCareEligibleItemswithintransaction". Qui sonne pour moi comme il le fait juste une chose: il compte le nombre d'éléments dans une transaction qui tombent dans une certaine catégorie. Bien sûr, je ne peux pas juger sans avoir vu le code de la méthode, mais qui sonne comme une bonne méthode pour moi.
Sur l'autre main, j'ai vu beaucoup de méthodes très court et concis des noms qui n'voie à beaucoup de travail, comme "processSale" ou le très populaire "doStuff".
Je pense qu'il serait difficile de donner un dur et rapide de la règle sur le nom de la méthode de la longueur, mais l'objectif devrait être: assez longtemps pour transmettre ce que la fonction n', assez courte pour être lisible. Dans cet exemple, je pense "getSkinCareCount" aurait sans doute été suffisant. La question est de savoir ce que vous avez besoin de les distinguer. Si vous avez une fonction qui compte soins de la peau-produits admissibles dans les opérations, et l'autre qui compte les soins pour la peau-éléments éligibles à quelque chose d'autre, puis "withinTransactions" ajoute de la valeur. Mais si ça ne veut rien dire pour parler des éléments en dehors d'une transaction, il est inutile d'encombrer le nom de ces informations superflues.
Deux, je pense que c'est très peu réaliste de supposer qu'un nom de n'importe quelle longueur maniable vous dira exactement quoi la fonction de tous, mais la plupart des cas triviaux. Un objectif réaliste est de se faire un nom qui donne au lecteur une idée, et qui peut se rappeler plus tard. Comme, si j'essaie de trouver le code qui calcule la quantité d'antimatière, nous avons besoin de consommer pour atteindre une vitesse de chaîne, si je regarde les noms de fonction et de voir "calibrateTransporter", "firePhasers", et "calcAntimatterBurn", il est assez clair que les deux premiers ne sont pas d'elle mais le troisième, peut-être. Si j'ai vérifier et de trouver que c'est bien la seule que je suis à la recherche, il est facile de se rappeler que, quand je reviens demain pour travailler sur ce problème un peu plus. C'est assez bon.
De trois, les noms longs sont similaires, sont plus à confusion que les noms courts. Si j'ai deux fonctions appelées "calcSalesmanPay" et "calcGeekPay", je peux deviner qui est qui au premier coup d'œil. Mais si, ils sont appelés "calculateMonthlyCheckAmountForSalesmanforexporttoaccountingsystemandreconciliation" et "calculateMonthlyCheckAmountForProgrammersforexporttoaccountingsystemandreconciliation", j'ai d'étudier les noms pour voir qui est qui. L'information supplémentaire dans le nom est probablement contre-productive dans de tels cas. Il s'avère une demi-seconde de penser à un 30-deuxième penser.
De la conception de votre interface de la façon dont vous voulez qu'il soit, et de faire de la mise en œuvre de match.
Par exemple, peut-être allais-je écrire que comme
ou avec Java 8 flux:
Ma règle est la suivante: si un nom est tellement longue qu'elle doit apparaître sur une ligne de son propre, puis c'est trop long. (Dans la pratique, cela signifie que je suis rarement au-dessus de 20 caractères.)
Ceci est basé sur des recherches montrant que le nombre de verticales apparentes lignes de code est corrélée positivement avec la codification de vitesse/efficacité. Si la classe/méthode de noms commencent considérablement mal à cela, ils sont trop longs.
Ajouter un commentaire où la méthode/classe est déclarée et laissez l'IDE de vous y emmener si vous voulez une description longue de ce qu'il est.
La longueur de la méthode elle-même est sans doute un meilleur indicateur de savoir si c'est d'en faire trop, et même ce qui ne vous donne qu'une idée approximative. Vous devez vous efforcer de concision, mais le descriptif est le plus important. Si vous ne pouvez pas la même signification dans un nom plus court, puis le nom lui-même est probablement correct.
Lorsque vous allez écrire un nom de méthode la prochaine fois , pense à le soufflet devis
Le nom de la méthode est vraiment trop long. Mon esprit a tendance à se promener quand je lis de telles de la taille des noms de méthode. C'est comme lire une phrase sans espaces.
Personnellement, je préfère que quelques mots dans les méthodes que possible. Vous êtes aidé si le package et le nom de la classe peut transmettre le sens. Si la responsabilité de la classe est très concis, il n'est pas nécessaire pour un géant du nom de la méthode. Je suis curieux de savoir pourquoi "WithinTransaction" sur on.
"getNumberOfSkinCareEligibleItemswithintransaction" peut devenir:
com.mycompany.app.produit.SkinCareQuery.getNumEligibleItems();
Puis lors de l'utilisation, la méthode pourrait ressembler à de la requête".getNumEligibleItems()"
Un nom de variable est trop long quand un nom plus court pour permettre une meilleure lisibilité du code sur l'ensemble du programme, ou les parties importantes du programme.
Si un nom plus long permet de transmettre plus d'information sur une valeur. Toutefois, si un nom est trop long, il est de l'encombrement du code et de réduire la capacité de comprendre le reste du code. Cela se produit généralement en provoquant la ligne continue et en poussant les autres lignes de code de la page.
Le truc, c'est de déterminer qui offrent une meilleure lisibilité. Si la variable est utilisé souvent ou plusieurs fois dans un court laps de l'espace, il peut être préférable de lui donner un nom court et utiliser un commentaire pour clarifier la situation. Le lecteur peut se référer à la remarque facilement. Si la variable est souvent utilisé tout au long du programme, souvent en tant que paramètre ou dans d'autres opérations complexes, il peut être préférable de couper vers le bas ou le nom, ou utiliser des acronymes, comme un rappel pour le lecteur. Ils peuvent toujours faire référence à un commentaire de la déclaration de la variable si ils en oublient le sens.
Ce n'est pas facile de faire des compromis pour faire, car vous devez tenir compte de ce que le lecteur de code est susceptible d'être essayer de comprendre, et également de prendre en compte la façon dont le code va changer et de grandir au fil du temps. C'est pourquoi, en nommant des choses est difficile.
La lisibilité est pourquoi il est acceptable d'utiliser j'ai comme un compteur de boucle, au lieu de DescriptiveLoopCounterName. Parce que c'est l'utilisation la plus courante pour une variable, vous pouvez dépenser le moins d'espace sur l'écran d'expliquer pourquoi il existe. Le plus long nom va juste perdre du temps en rendant plus difficile de comprendre comment tester la condition de la boucle ou de l'indexation dans un tableau.
Sur l'autre extrémité du spectre, si une fonction ou une variable est rarement utilisé comme une opération complexe, comme le fait d'être passé à un multi-paramètre de l'appel de fonction, vous pouvez vous permettre de lui donner une trop nom descriptif.
Comme avec tout autre langage: quand il n'est plus décrit l'action simple de la fonction s'exécute.
Je dirais que l'utilisation d'une combinaison de la bonne réponses et d'être raisonnable.
Complètement, clairement et lisiblement décrire ce que la méthode ne.
Si le nom de la méthode semble trop longue, refactoriser le code de la méthode d'en faire moins.
C'est trop long lorsque le nom de la méthode se terminera sur une autre ligne et l'appel à la méthode est la seule chose sur la ligne et commence assez proche de la marge. Vous devez prendre en compte la moyenne de la taille de l'écran des gens qui vont l'utiliser.
Mais! Si le nom semble trop long, alors il est probablement trop long. La façon de la contourner est d'écrire votre code dans une telle manière que vous êtes à l'intérieur d'un contexte, et le nom est court, mais dupliqué dans d'autres contextes. C'est comme quand vous pouvez dire "elle" ou "il" en anglais à la place de quelqu'un du nom complet.
Il est trop long, trop verbosively explique ce que la chose est.
Par exemple, ces noms sont fonctionnellement équivalents.
en Java:
java.sql.SQLIntegrityConstraintViolationException
en Python/Django:
django.db.IntegrityError
Demandez-vous, dans un SQL/db paquet, combien d'autres types d'erreurs d'intégrité pouvez-vous venir avec? 😉
Donc
db.IntegrityError
est suffisant.Un nom d'identificateur est trop long quand il dépasse la longueur de votre compilateur Java peut gérer.
Il y a deux façons ou les points de vue ici: l'Une est qu'il n'a vraiment pas d'importance combien de temps le nom de la méthode est, aussi longtemps que c'est aussi descriptif que possible pour décrire ce que cette méthode est en train de faire (Java meilleures pratiques règle de base). En revanche, je suis d'accord avec le flybywire post. Nous devons utiliser notre intelligence pour essayer de réduire autant que possible le nom de la méthode, mais sans le réduire de son caractère descriptif. Le caractère descriptif est le plus important 🙂
Un nom est trop long si c':
Honnêtement le nom ne doit transmettre son but pour les Développeurs qui pourront l'utiliser comme une méthode de l'API publique ou qui ont pour maintenir le code lorsque vous quittez. Rappelez-vous juste KISS (keep it simple stupid)