Quels anti-modèles de nommage existent? [fermé]

Il y a des noms, où si vous vous trouvez à chercher ces noms, vous savez que vous avez déjà foiré quelque chose.

Par exemple:

XxxManager
Cela est mauvais car une classe doit décrire son travail. Si le mot le plus spécifique que vous puissiez trouver pour ce que la classe fait est "gérer", alors la classe est trop grosse.

Quels autres anti-modèles de nommage existent?

Pour clarifier, je ne demande pas "quels noms sont mauvais" - cette question est entièrement subjective et il n'y a aucun moyen d'y répondre. Je demande, "quels noms indiquent les problèmes globaux de conception avec le système." Autrement dit, si vous souhaitez appeler un composant Xyz, cela indique probablement que le composant est mal conçu. Notez également qu'il existe des exceptions à chaque règle. Je recherche simplement des indicateurs d'avertissement lorsque j'ai vraiment besoin d'arrêter et de repenser un dessin.

Les anti-modèles de dénomination suivants sont liés à .NET et, en particulier, à C #:

• Incohérences . Si vous avez décidé de commencer chaque nom de champ par un trait de soulignement, respectez-le .
• Abréviations Ambiguos avec voyelles manquantes . J'ai sérieusement vu des noms de champs tels que cxtCtrlMngr. Vous pouvez difficilement deviner ce que cela est supposé représenter.
• Noms de variable trop longs et trop détaillés . ILoginAttemptRepositoryest bien et descriptif - ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMappingest descriptif, mais certainement pas bien.

L'une de celles que je rencontre souvent est tout simplement de ne pas utiliser de modèle de dénomination. Cela indique généralement l'ignorance des développeurs (que les modèles de nommage sont une bonne chose ) et que cet anti-modèle a tendance à violer de manière flagrante le PRS en fourrant toutes sortes de méthodes liées à une classe dans cette classe elle-même, par exemple un client La classe a des propriétés, des méthodes CRUD, tout ce qui concerne un client dont une partie de l'application a besoin.

J'ajouterai également qu'utiliser "Engine" comme suffixe revient à peu près à utiliser "Manager". C'est très vague et une classe appelée a XxxEnginetendance à être ce qui équivaut à un module de style VB contenant un tas de méthodes, donc c'est un endroit "facile à utiliser", sans aucune connaissance ni idée de la programmation orientée objet.

Eh bien, les réponses les plus simples en premier lieu: tapez hongrois ( http://mindprod.com/jgloss/unmainnaming.html , a également d’autres idées intéressantes. Un point de vue plus équilibré sur les cas où l’hongrois n’est pas mauvais, http://www.joelonsoftware.com /articles/Wrong.html )

Préfixer un 'I' au nom d'une interface ou 'Abstract' au nom d'une classe abstraite. Cela peut être excusable dans des langages qui n'ont pas le concept de classes abstraites, ou qui ne font pas la différence entre les interfaces et les classes abstraites - mais en Java, par exemple, c'est toujours une mauvaise idée.

De plus, je ne suis pas d'accord avec vous sur la question du gestionnaire. J'utilise parfois ce modèle, et cela signifie simplement que si j'essayais de le nommer autrement, le nom ne serait pas plus descriptif que XxxxxManager. Certaines tâches (pas nécessairement complexes) ne peuvent tout simplement pas être résumées en un ou deux mots.

Speeling:

J'ai un handicap mental et je ne peux pas épeler. Sans le correcteur orthographique, je suis impuissant. J'essaie de copier tous les noms que je crée dans un traitement de texte pour vérification, mais j'en manque toujours. Lors de mon dernier projet, j'ai écrit une grande partie de l'API et je suppose que je n'ai pas vérifié l'orthographe la première fois que j'ai utilisé le mot réponse et j'ai supposé que c'était juste parce que personne ne me l'avait dit. Nous avions au moins 50 fonctions avec réponse dans celui-ci. Une nouvelle personne est venue dans l’équipe et a demandé pourquoi nous utilisions la réponse Je me sentais vraiment stupide.

Eh bien, j'ai peur que mes opinions soient un peu controversées. Mais essayons ...

En ce qui me concerne, je suis d’accord avec Mike Baranczak, des noms tels que XxxController, XxxHandler est quelque chose que nous utilisons très souvent. Pour nous, un contrôleur est quelque chose comme un point d’entrée pour quelque chose "encapsulé", par exemple la gestion de transactions, le traitement d’erreurs inattendues, l’appel de XxxHandler pour effectuer le travail réel. Je dirais qu'un XxxManager est un synonyme de contrôleur. Je pense qu'il est important de ne pas utiliser Manager dans un cas et Controller dans un autre. Être cohérent est très important si vous travaillez en équipe.

Ce serait vraiment difficile, voire impossible, de trouver de meilleurs noms pour des choses comme celle-là. Xxx devrait être bien choisi pour rendre la situation plus claire.

Ce que je n'aime pas personnellement, c'est quand une méthode appelée get ... ou set ... est plus qu'un simple accesseur. J'aime det ... pour déterminer.

Une autre chose qui me vient à l’esprit: selon l’oncle Bob. Un "Et" dans un nom de méthode est un signe de faire trop. Mais la vie n’est pas toujours noire ou blanche - il y a des situations où je pense que ça va - par exemple. en raison de problèmes de performances (lorsque vous avez déjà les données à vérifier, pourquoi ne pas les traiter) ...

Personnellement, je suis aussi un grand fan de la notation hongroise des systèmes - la plupart du temps, vous avez affaire à du code source dans un IDE ok. Mais souvent, vous utilisez uniquement un éditeur ou vous parcourez le référentiel dans un navigateur. Un des inconvénients peut être le support d’outils dû aux préfixes de type ...

Je pense que la chose la plus importante est d'être fidèle - une convention sous-optimale - pour moi - vaut mieux que de ne pas avoir de convention ...

Peut-être le pire anti-modèle de dénomination est-il

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

Nous avons une liste à trois éléments de paires [foo, bar]. Si nous en avons besoin d'une quatrième, nous devrons ajouter de nouvelles colonnes à la table.

Conduisant à coder comme ceci:

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

Un tableau séparé doit être créé avec les colonnes foo et bar et lié au tableau de commandes:

create table fubar(foo string, bar string, stuff_id long)

Le deuxième pire est celui-ci:

class Student {
  ...
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;
  ...
}

Ici, nous avons six champs au lieu de deux instances d'une classe d'adresse.

Cet anti-motif est marqué par une série de noms en deux parties listant chaque combinaison de deux ensembles, par exemple [foo, bar] x [1,2,3] ou [home, perm] x [rue, ville, état]

Toute dénomination de classe ou d’interface qui est une tautologie est mauvaise, pas seulement en Java dont parle le lien, mais dans n’importe quel langage.

Tautologie (rhétorique), utilisant des mots différents pour dire la même chose même si la répétition ne fournit pas de clarté.

Je rencontre fréquemment des bibliothèques de logiciels portant des noms génériques tels que Libraryou Common. Ils indiquent une conception non optimale: les développeurs s'efforcent d'éviter la duplication de code, mais sans chercher à créer une conception décomposée sur la base de la fonctionnalité.

De Microsoft en nommant, je peux fournir cette liste pour les mauvais noms:

1. Ils ne sont pas sémantiques, ce qui signifie qu'ils ont des noms qui, au lieu d'insister sur ce qu'ils font, mettent l'accent sur la technologie utilisée ou le modèle sur lequel elle est basée .
2. Ils ne suivent pas une cohérence syntaxique. Par exemple, une partie des noms sont à boîtier chameau, tandis que l’autre partie est à boîtier calin.
3. Ce sont des abréviations difficiles à comprendre, comme ScrollableX au lieu de CanScrollHorizontally
4. Ils sont choisis de manière à déranger les mots-clés de cet environnement.