Je suis tombé sur quelques articles comme Celui-ci , lequel Suggérez que certains mots ne doivent jamais être utilisés dans le cadre d'un nom de classe. Lorsqu'un cours a un de ces mots dans le nom, cela signifie que le code doit être refactored ou repensé.
Exemple:
manager
Raison: depuis presque toutes les classes "gérer" quelque chose et la signification du "gestionnaire" est très large, les gens peuvent mettre beaucoup de responsabilités à une classe "gestionnaire" tout en pouvant réclamer la classe "une seule chose ". En conséquence, nommer une classe avec «gestionnaire» ne dit pas grand chose de ce que fait la classe. L'article mentionné précédemment, "Nommer les classes Java sans" Manager "" , a montré ce point:
Par exemple, prenez une classe nommée "URLManager" - vous ne pouvez pas dire si elle utilise des URL de pool, manipule les URL ou audite l'utilisation d'eux. Tout ce que vous vous dit que ce n'est pas une URL, mais cela fonctionne en quelque sorte avec eux. D'autre part, le nom "Urlbuilder" donne une image bien meilleure de ce que la classe fait.
Un autre exemple:
Raison: un nom de classe comme "Threadhelper" fait se demander aux gens pourquoi il est nécessaire et pourquoi il ne peut pas simplement faire partie de la classe "thread". Est-ce en fait un adaptateur ou un décorateur? Si oui, nommez-le comme ça. La classe "fil" est-elle déjà une plus grande responsabilité? Si oui, refacteur et donnez le nouveau nom de classe un nom significatif. "Helper" ne dit rien sur ce que ça fait ou comment ça aidait.
Quels sont les autres mots d'un nom de classe qui signalerait un besoin de refactoring ou de refonte et devraient être évités? Pourquoi?
Edit: Je pense que ces mots sont utilisés beaucoup depuis
Le livre Clean Code énumérés plus mais aucune raison n'a été donnée:
Évitez les mots comme gestionnaire, processeur, données ou informations au nom d'une classe.
Ce serait génial si une personne pouvait les fournir possibles les raisons.
Questions connexes:
11 Réponses :
Liste des mauvaises idées pourraient prendre cesse un moment, juste en haut de ma tête, je pouvais penser à beaucoup de mauvais noms: lecteur, écrivain, article, article, minuterie, reciever, expéditeur, etc.
Fondamentalement, évitez les noms qui ne vous donnent aucun contexte pour ce que la classe est ou son rôle dans la plus grande image. Il n'est pas nécessaire de faire un jour aussi sur le dessus que ihelptosendxmldatatotheserver , mais éventuellement xmlbroadcastutil ne serait pas terrible. Certaines personnes vont même jusqu'à ajouter un préfex particulier, suffixe aux noms de classe à désigner quel module il fonctionne avec. Cependant, je dirais que cela fait partie du rôle de l'espace de noms / paquet.
"Récepteur" tombe dans mon "Je déteste ça parce que c'est une règle mal orthographiée".
IHELPTHEHELPERSENDXMLAATATOTHESERVERBYENCODINGITSJSJSJSJSJSJUSES
résumé Modèle Modèle Usine Objet
Ce sont tous vraiment génériques et certains d'entre eux pourraient être évidents de la définition de la classe. D'autres sont évidemment mieux notés dans un peu de documentation (une référence facile de laquelle est une raison d'aimer Restomer)
Vous vous conseilleriez donc de ne pas appeler des cours en chambre si la classe générerait des chambres pour un labyrinthe dans une partie?
Je comprends que des gens comme le modèle d'usine abstrait et tels. Mais je ne suis tout simplement pas nommé les cours de cette façon. En outre, si j'avais une classe qui génère des chambres, je commencerais en me demandant si je ne pouvais pas simplement définir un groupe de nouvelle chambre () ou l'appeler roominit (), etc.
1) quelque chose de moins de 3 caractères se fait vraiment sur mes nerfs. Cela fait vraiment mal à la lisibilité, car 3 caractères au moins vous donne au moins une voyelle. Personnellement, j'essaie d'utiliser au moins 5 caractères.
2) Une peste d'animal de compagnie que j'ai est des noms de classe se terminant en classe (EX: PersonClass ou ButtonClass), car il est en quelque sorte éloigné du fait que vous faites un objet, pas une classe. De la même manière que vous trouverez OK (EX: Bluebutton, Redlabel), car il est plus facile de lire, mais la classe peut être vraiment ennuyeuse.
@nilamo Oui, ce serait plutôt mauvais, mais aussi blueclass ou buttonclass @ martlark c'est en fait bête ...
Tout ce qui peut remplacer les classes standard (ex: comparateur , ibler & c. en Java), à moins que vous ne comprenez et envisagez spécifiquement de causer ce type de comportement.
Je pense que cette question doit être vue dans la plus grande image de choisir le bon nom pour tout moyen . Quand ma femme me demande d'avoir quelque chose du placard, comment suis-je censé savoir quel placard elle signifie?
Peut-être des objets de ma classe faire créer des boutons, alors pourquoi ne pas l'appeler un bouton de boutonnière? Peut-être que cet objet gère la durée de vie des fichiers temporaires, appelons-le temporairementfileManager.
Le problème se pose lorsque vous n'avez pas assez d'informations contextuelles. Ceci est particulièrement difficile lors de la création de composants réutilisables: Mon temporaireFileManager peut être une sous-classe d'une classe de gestionnaire générique et mon bouton de boutonnière peut être un cas particulier de Widgetsfactory.
Tant que le nom décrit ce que la chose dans son contexte je vais bien. Et c'est ce que l'article mentionné est à propos.
Mes identifiants préférés en général sont:
2 est à la hauteur de la police que vous choisissez de le voir.
Le problème n'est pas vraiment en train d'être un 1 ou et moi, ou un 0 ou un O. le problème est qu'il s'agisse d'un chiffre. Vérifiez la réponse de EED3SI9N ci-dessous.
articles ( pronoms et noms ( numéros, à l'exception des versions spécifiques ( Adjectifs moelleux ( langue étrangère que la majorité de l'équipe ne comprenne pas (εληνικά) le , a , an )
mon , leur , john )
2 , 3 , 5000 )
rapide , intelligent , bon , meilleur ) )
C'est toujours un mauvais appel.
n'importe quel nom contenant des caractères qui ne sont pas 7 bits ASCII.
Je ne peux vraiment pas comprendre ni même modifier des caractères hindi. p>
class हिनà¥à¤¦à¥€:হিনà§à¦¦à§€ ঠার
{
// argh..
}
Bien sûr, il serait préférable que tout le monde écrit leur code en anglais. Mais si certains de toute façon écrivent du code dans leur langue maternelle, ils pourraient également utiliser les caractères de leur langue (si le langage de programmation prend en charge les identificateurs UNICODE, tels que Java le fait). De toute façon, les étrangers ne le comprendront pas, mais les locuteurs natifs peuvent mieux le comprendre, surtout s'il n'y a pas de conversion 1: 1 vers et des caractères américains ASCII (par exemple, chinois).
Si l'équipe écrit toujours du code dans leur langue maternelle, je ne suis pas une chose que vous devriez refroidir à cause de cela.
L'anglais n'est pas ma langue maternelle non plus. L'anglais n'est pas seulement la langue internationale d'aujourd'hui, c'est la langue des programmeurs, peu importe où vous êtes. J'insiste que les noms non anglais sont une odeur de code. Si vous ne maîtrisez pas l'anglais, votre éducation a sucé beaucoup de temps (sérieusement, récupérer votre argent). Il est essentiel pour les programmeurs: les langages de programmation, les bibliothèques, la documentation et de nombreuses informations importantes sur le net sont uniquement disponibles en anglais (pas de scaleverflow pour vous si vous ne parlez pas anglais). Je ne laisserais personne qui ne parle pas anglais touche un code sous ma supervision.