Par exemple, prenez ce morceau de code:
var person = new Person();
ou pour vous les Pythonistes:
person = Person()
On me dit constamment à quel point c'est mauvais, mais je n'ai pas encore vu d'exemple de l'immoralité de ces deux lignes de code. Pour moi, une personne est une personne et essayer de lui donner un autre nom est une perte de temps. Je suppose que dans les jours qui ont précédé la coloration syntaxique, cela aurait été un gros problème. Mais ces jours-ci, il est assez facile de distinguer un nom de type d'un nom de variable. Heck, il est même facile de voir la différence ici sur SO.
Ou y a-t-il quelque chose qui me manque? Si tel est le cas, il serait utile que vous fournissiez un exemple de code qui pose des problèmes.
Person Person=new Person();
à ce sujet? Comme indiqué dans The Question, nous vivons à une époque où la mise en évidence de la syntaxe et la reconnaissance du contexte sont si incroyables que mon compilateur ne s'est jamais plaint que je fasse exactement cela. J'adore mes variables CamelCased - pourquoi ne le devrais-je pas (dans des situations où ilPerson Person
y a une instanciation générale et unique de la classe et aucun conflit n'est présent ni possible)?Réponses:
Quel est le raisonnement de ceux qui vous disent que c'est mauvais? Je le fais tout le temps. C'est le moyen le plus simple et expressif de nommer une seule variable d'un type. Si vous aviez besoin de deux
Person
objets, vous pourriez préfixerperson
avec des adjectifs significatifs commesinon juste
ça me va.
la source
J'utilise beaucoup ce modèle dans les signatures de méthode. Si je suis incapable de fournir un autre nom descriptif, alors à mon humble avis, il n'y a rien de mal à cela.
Ce qui ne va pas, ce serait si vous avez deux types de personne et de personne, alors c'est très très faux.
la source
Je l'utilise tout le temps pour les références d'objets temporaires. Je l'éviterais comme le fléau des types de données primitifs.
la source
Si quelqu'un dit que c'est mal, demandez-lui si c'est mieux:
la source
var temp = new Person();
(Clause de non-responsabilité: je sais qu'il y a vraiment des endroits pour une fois utiliser des variables temporaires, mais aussi souvent que pas quand je vois cela dans le code de quelqu'un, l'auteur n'a tout simplement jamais recommencé à donner au var un nom approprié et cela peut ainsi être "abc".)Si la personne est une personne générale dans le contexte, alors «personne» est un très bon nom. Bien sûr, si la personne a un rôle spécifique dans le code, il est préférable de la nommer en utilisant le rôle.
la source
Je suppose que je vais être critiqué pour l'avoir dit, mais ...
Ayant juste traversé un siècle d'assassinat épique et de cupidité, nous, les programmeurs, sommes vraiment bénis si la chose la plus immorale que nous puissions faire est de nommer une variable.
la source
Je ne pense pas que ce soit nécessairement «mauvais», mais évidemment si vous pouvez le qualifier pour lui donner plus de contexte, comme quel genre de personne il s'agit (vous avez affaire à une seule des personnes probablement possibles), alors quelqu'un d'autre le choisit up peut mieux comprendre.
la source
Jason - Je ne sais pas qui vous a dit que c'était mauvais. Un certain nombre d'auteurs l'utilisent comme moyen standard d'exprimer une instance (minuscule) d'une classe (en majuscule).
J'utilise cela assez souvent car je trouve que la variable minuscule me communique en fait non seulement qu'il s'agit d'une instance mais aussi le nom de la classe.
À moins que quelqu'un ait un argument solide en faveur du contraire, je continuerai certainement à le faire.
la source
La raison pour laquelle il est considéré comme mauvais est que si vous avez besoin d'avoir 2 personnes à l'avenir, vous pouvez alors vous retrouver avec un code qui ressemble à.
Personne personne = nouvelle personne ();
Personne person2 = nouvelle personne ();
Ce serait alors à la limite de "Bad". Cependant, dans ce cas, vous devez alors refactoriser votre personne d'origine afin de faire la distinction entre les deux.
Comme pour votre exemple, le nom de variable "personne" est un nom parfaitement descriptif pour l'objet "Personne". Il n'y a donc rien de mal à cela.
la source
Je dis nom pour ce que c'est: si la variable représente une personne avec 2 chiens, appelez-la
personWith2Dogs
. Si la variable a une portée courte (comme une boucle var), la personne va bien.la source
J'utilise beaucoup cela dans mon code et je ne pense pas qu'il y ait quelque chose qui cloche. Cela dit, je ne l'utiliserais (probablement) pas dans une méthode plus longue que, disons, un écran, et s'il y a plusieurs instances de la classe Person. Ne les nommez certainement pas person1, person2, person3 ... utilisez plutôt quelque chose de plus descriptif, comme person_to_del, person_to_ban, person_to_update, etc.
la source
Pas immoral, mais une recherche globale trouvera les deux
Person
etperson
si vous ne parvenez pas à activer la sensibilité à la casse. Je préfère un préfixe pour faciliter la recherche / remplacement global, mais absolument PAS le hongrois ou quelque chose de long / compliqué. Alors, j'utilise ...Person
pour la classe / typeaPerson
pour une variable localethePerson
pour un paramètre de méthodemyPerson
pour une variable d'instanceourPerson
pour une variable de classeEn de rares occasions, je pourrais utiliser
p
dans un contexte local où j'ai BEAUCOUP de références, mais cela ne s'applique généralement qu'aux index de boucle et autres.la source
Ça dépend.
Si vous avez un style de capitalisation strict, donc les variables commencent en minuscules (et utilisez soit under_scores ou camelCase pour les sauts de mots), et les classes commencent par des majuscules, alors il est évident que personne est une variable et Person est une classe, et quand quelqu'un comprend cela , ils ne semblent pas se trouver dans des espaces de noms qui se chevauchent. (De même, les gens ne se confondent presque jamais entre le verbe ou le nom «polonais» et l'adjectif «polonais».)
Si vous n'avez pas un tel style, alors vous avez deux noms qui peuvent facilement être confondus et qui ne diffèrent que par casse. C'est mauvais.
la source
Quels sont les arguments exacts que ces gens utilisent?
S'ils ne vous permettent pas d'utiliser la personne comme nom de variable, vous pouvez envisager d'ajouter le préfixe «a».
la source
Je pense que ce que vous faites est bien. Je pense qu'en général, il est important d'avoir des normes de codage convenues.
Par exemple, j'utilise lowerCamelCase pour les instances, les variables et UpperCamelCase pour les classes, etc.
Les normes de codage devraient éliminer ce problème.
Quand je regarde des programmes open source réussis, ils ont souvent des normes de codage
http://drupal.org/coding-standards
http://help.joomla.org/content/view/826/125/
http://wiki.rubyonrails.org/rails/pages/CodingStandards
http://lxr.linux.no/linux/Documentation/CodingStyle
Accepter les normes de codage devrait être la dernière bataille que vous ayez à ce sujet.
En fait, regardez l'entrée wikipedia (de http://en.wikipedia.org/wiki/CamelCase )
Style de programmation et de codage
La capitalisation interne est parfois recommandée pour indiquer les limites des mots par les directives de style de codage pour l'écriture du code source (par exemple, le langage de programmation Mesa et le langage de programmation Java). Les recommandations contenues dans certaines de ces directives sont prises en charge par des outils d'analyse statique qui vérifient le code source pour la conformité.
Ces recommandations font souvent la distinction entre UpperCamelCase et lowerCamelCase, spécifiant généralement la variété à utiliser pour des types d'entités spécifiques: variables, champs d'enregistrement, méthodes, procédures, types, etc.
Un style de codage Java largement utilisé dicte que UpperCamelCase soit utilisé pour les classes, et lowerCamelCase pour les instances et les méthodes. [19] Reconnaissant cet usage, certains IDE, comme Eclipse, implémentent des raccourcis basés sur CamelCase. Par exemple, dans la fonction d'assistance de contenu d'Eclipse, taper uniquement les lettres majuscules d'un mot CamelCase suggérera un nom de classe ou de méthode correspondant (par exemple, taper «NPE» et activer l'assistance de contenu pourrait suggérer «NullPointerException»).
La notation hongroise originale pour la programmation spécifie qu'une abréviation minuscule pour le "type d'utilisation" (et non le type de données) doit précéder tous les noms de variables, le reste du nom étant en UpperCamelCase; en tant que tel, il s'agit d'une forme de lowerCamelCase. CamelCase est la convention officielle pour les noms de fichiers en Java et pour l'ordinateur personnel Amiga.
Microsoft .NET recommande lowerCamelCase pour les paramètres et les champs non publics et UpperCamelCase (alias "Pascal Style") pour les autres types d'identificateurs. [20]
Python recommande UpperCamelCase pour les noms de classes. [21]
Le registre NIEM exige que les éléments de données XML utilisent UpperCamelCase et les attributs XML utilisent lowerCamelCase.
Il n'y a pas de convention unique pour l'inclusion d'abréviations majuscules (principalement des acronymes et des initialismes) dans les noms CamelCase. Les approches incluent de laisser l'abréviation entière en majuscules (comme dans "useHTTPConnection") et de ne laisser que la première lettre en majuscules (comme dans "useHttpConnection").
L'étui Camel n'est en aucun cas universel en informatique. Les utilisateurs de plusieurs langages de programmation modernes, notamment ceux des familles Lisp et Forth, utilisent presque toujours des tirets. Parmi les raisons parfois invoquées, citons le fait que cela ne nécessite pas de changement sur la plupart des claviers, que les mots sont plus lisibles lorsqu'ils sont séparés et que la casse de chameau peut tout simplement ne pas être conservée de manière fiable dans les langues insensibles à la casse ou à casse (comme Common Lisp, qui, bien que techniquement un langage sensible à la casse, canonise (plie) les identifiants en majuscules par défaut).
la source
Il est possible de faire valoir avec plus de force que les noms de méthodes de ce type sont non seulement inoffensifs, mais peuvent également être un indicateur de code de bonne qualité.
Un indicateur d'une bonne granularité du code: si vos méthodes sont courtes, à usage unique et nommées de manière descriptive, vous n'avez pas besoin de beaucoup d'informations dans les noms de variables. Si vous avez de longues méthodes qui font beaucoup de choses et que vous avez besoin de garder une trace de beaucoup de contexte et d'état, alors vos noms de variables doivent être plus descriptifs.
Un indicateur des calculs à usage général poussés vers des méthodes à usage général: si vous effectuez une manipulation intermédiaire des structures de données dans une méthode métier, par exemple un tableau d'utilisateurs doit être dédupliqué, vous devrez avoir des variables dans la portée avec des noms comme
users[]
etdeduplicatedUsers[]
. Si vous déplacez la déduplication vers une méthode utilitaire, vous pouvez appeler la méthodeUtils.dedup(array)
, et vous pouvez appeler le tableau dédupliquédeduplicatedArray
ou simplementresult
.Les décompilateurs Java utilisent souvent un schéma comme celui pour nommer les variables locales (les variables d'instance et de classe sont normalement disponibles dans le bytecode, mais les variables locales ne le sont pas), et les résultats sont plus lisibles que vous ne le pensez, en fait souvent plus lisibles que le source primaire.
Voir le principe de Larry Wall «L'ambiguïté locale est OK» - http://www.wall.org/~larry/natural.html .
la source
Je dirais que vous avez probablement une utilisation spécifique à l'esprit chaque fois que vous créez un objet. Le type seul reflète très rarement cette utilisation.
Donc, si vous souhaitez créer un nouveau contact dans votre application de carnet d'adresses, vous pouvez appeler la variable
newContact
.Et si vous effectuez un test unitaire de votre code pour vérifier le comportement des
Person
objets sans nom défini, vous pouvez les appelerunnamedPerson
ou quelque chose de similaire.L'appeler
person
renonce simplement à une grande chance de rendre votre code auto-documenté.la source
var he_who_must_not_be_named = new Person();
? :-)Seulement si vous programmez en VB6. Dans ce cas , ce que vous faites est illégal, mais pas immoral.
la source
Je le fais aussi, et je ne comprends pas non plus pourquoi cela devrait être «immoral». Bien que je puisse comprendre que cela `` puisse '' parfois être déroutant, mais aujourd'hui, nous avons des IDE avec Intellisense et la coloration syntaxique qui garantira que (si vous faites une erreur et référencez votre variable au lieu de votre classe, et vice versa) vous voyez votre erreur assez rapidement. Et nous avons également le compilateur. :)
la source
Je ne vois pas non plus de problème avec cette pratique. Tant qu'il n'y a qu'une seule variable de cette classe, elle est facile à écrire et à lire. Imo, cela s'applique même dans un éditeur de texte de base. Personnellement, je ne me souviens pas que quelqu'un ait qualifié cela de mauvais ou même d'immoral. Continuez simplement à faire ceci :)
la source
Je pense que la «règle» à laquelle vous pensez peut-être est plus destinée aux types primitifs et aux classes où le nom de classe fait un mauvais nom de variable.
Par exemple, si vous deviez calculer le coût d'un article particulier dans une boutique en ligne, le code suivant ne serait pas de bonne forme:
Au lieu de cela, un nom plus descriptif serait conseillé, tel que «_total» ou «_cost».
la source
Le seul problème avec ce genre de chose que j'ai trouvé est si vous voulez le même nom pour un membre privé et aussi une propriété publique.
Si ceux-ci ne diffèrent que par casse, cela fonctionnera bien dans les langages sensibles à la casse tels que C #, mais pas dans VB.NET.
Donc, par exemple, en VB, j'écrirais
mais
Je ferais la même chose en C #, pour que la traduction de l'un à l'autre soit indolore. Cela le rend également un peu moins sujet aux erreurs, car il est très facile de mal lire ou même de taper des mots qui ne diffèrent que par cas.
la source
Pas immoral, mais si votre meilleur nom pour votre variable est le nom du type, quelque chose ne va pas ou vous faites simplement une preuve de concept ou quelque chose comme ça. Pour moi, un nom de variable doit faire référence à la signification dans le contexte commercial et non au langage de programmation. Il sera plus difficile de comprendre le code.
la source
J'utilise souvent
Person person = new Person()
moi-même. Couramment utilisé en Java / C #.Même si j'ai fini par me demander hier pourquoi
ne fonctionne pas en C # ...
Surtout voir comment vous pouvez utiliser
String
,string
,Double
,double
, ... à volonté en C #.la source
est bien dans mon livre.
Quand cela devient horrible, c'est quand vous avez:
Très facile à mélanger les 2.
la source
Ce qui m'a été dit, à part le fait de ne pas respecter nos normes de codage, c'est d'éviter d'ajouter de la confusion lorsque quelqu'un d'autre lit mon code. Personnellement, je n'y vois aucun problème, tant que le sens est clair.
En ce qui concerne les types CLR (int, string, etc.), vous pouvez utiliser String ou string (etc.) pour déclarer le type, donc j'éviterais d'utiliser quelque chose comme
la source
Faire de la capitalisation la seule différence est dangereux ... continuez à faire cela pour un gros projet et je vous garantis vous que vous rencontrerez des erreurs bizarres que vous ne parvenez pas à localiser.
fastPerson / slowPerson comme ci-dessus sont très bien ... ils sont descriptifs et différenciés du nom du type de variable ... mais allez man, appeler un int "Int" serait tout simplement paresseux.
la source
Je dirais que ce n'est jamais immoral - c'est vraiment juste votre nom de variable de base. Si vous ne pouvez pas penser à un meilleur nom, le nommer après son type est une bonne valeur par défaut. (Pour les types complexes uniquement - pour les types intégrés, c'est mal ) t savoir autre chose sur la variable. Comme avec cette méthode
La seule chose que vous pourriez raisonnablement appeler une personne est
person_to_save
ou quelque chose comme ça qui semble redondant.Cependant, dans de nombreux cas, vous pouvez améliorer la lisibilité de votre code en remplaçant la personne par un nom plus descriptif. Par exemple, c'est moins descriptif
que ça
Cependant s'il vous plaît, s'il vous plaît - joli s'il vous plaît ne mettez pas un 'a' ou 't' devant le nom du type. IE aPerson pour «une personne» ou tPerson pour «la personne». C'est trop compliqué et n'ajoute pas beaucoup de valeur, voire aucune. De plus, vous commencez à polluer votre portée avec un tas de variables qui commencent par a ou t, ce qui peut minimiser la valeur d'intelli-sense.
la source
Je ne dirais pas que c'est horrible. Je préfixe généralement le nom de la variable avec `` a '' dans ce genre de chose pour montrer qu'il s'agit d'une seule instance du type, donc je ferais
Cela rend le code plus naturel, je pense.
la source
Absolument rien de mal à cela, sous réserve des mises en garde soulignées par d'autres (résumant ici pour plus de commodité): ne pas le faire avec des types primitifs, refactoriser l'instance d'origine si une autre instance est ajoutée plus tard, ne pas utiliser char-case pour différencier les noms de classe, etc.
Ma règle d'or? Les instructions dans le code doivent se lire comme de simples phrases anglaises.
Personne personne = nouvelle personne ();
Employé employé = person.getRole (EMPLOYEE);
Parent parent = person.getRole (PARENT);
person.getFullName ();
employee.getSalary ();
parent.getChildren ();
parent.getFullName (); // en assumant le motif du décorateur en jeu
if (person.hasRole (EMPLOYEE)) {
...
}
Et ainsi de suite.
Si la portée de la variable est limitée (la méthode d'encapsulation est de 10 à 15 lignes, par exemple), je pourrais même utiliser «p» au lieu de «personne». Les noms de variables plus courts sont moins une distraction lorsque vous essayez de garder le contexte dans votre tête. Évitez les préfixes gratuits tels que «a» ou (frisson) la notation hongroise et ses dérivés. (Remarquez que je n'ai rien contre de tels préfixes lorsqu'ils sont utilisés dans le contexte approprié - code API C ++ / COM / ATL / Win32, etc., où cela aide à garder les affectations / la typographie droite).
Mes deux (!) Bits :-)
la source