Suis-je immoral pour avoir utilisé un nom de variable qui ne diffère de son type que par cas?

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.

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 Personobjets, vous pourriez préfixer personavec des adjectifs significatifs comme

fastPerson
slowPerson

sinon juste

person

ça me va.

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.

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.

Person person = new Person(); // okay

int Int = 42; // pure evil

Si quelqu'un dit que c'est mal, demandez-lui si c'est mieux:

var abc = new Person();

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.

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.

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.

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

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.

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.

Pas immoral, mais une recherche globale trouvera les deux Personet personsi 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 ...

Personpour la classe / type aPersonpour une variable locale thePersonpour un paramètre de méthode myPersonpour une variable d'instance ourPersonpour une variable de classe

En de rares occasions, je pourrais utiliser pdans 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.

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

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

aPerson = Person()

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

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[]et deduplicatedUsers[]. Si vous déplacez la déduplication vers une méthode utilitaire, vous pouvez appeler la méthode Utils.dedup(array), et vous pouvez appeler le tableau dédupliqué deduplicatedArrayou simplement result.

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

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 Personobjets sans nom défini, vous pouvez les appelerunnamedPerson ou quelque chose de similaire.

L'appeler personrenonce simplement à une grande chance de rendre votre code auto-documenté.

Seulement si vous programmez en VB6. Dans ce cas , ce que vous faites est illégal, mais pas immoral.

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

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

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:

Decimal _decimal = item.BaseCost + item.Tax;

Au lieu de cela, un nom plus descriptif serait conseillé, tel que «_total» ou «_cost».

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

Private _name As String

mais

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

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.

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.

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

private enum DataType {NEW, OLD}

ne fonctionne pas en C # ...

Surtout voir comment vous pouvez utiliser String, string, Double, double, ... à volonté en C #.

Person person = new Person()

est bien dans mon livre.

Quand cela devient horrible, c'est quand vous avez:

string Person;
string person;

Très facile à mélanger les 2.

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

int Int = 0;
string String = "hi there";

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.

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

void SaveToDatabase(Person person) {...}

La seule chose que vous pourriez raisonnablement appeler une personne est person_to_saveou 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

void AddToAccount(Account account, Person person)  {...}

que ça

void AddToAccount(Account account, Person dependent)  {...}

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.

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

Person aPerson = new Person();

Cela rend le code plus naturel, je pense.

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