Les directives relatives aux conventions de dénomination valent-elles la peine d'être prises en compte?

13

Je nomme mes variables en utilisant les conventions .Net:

  • camelCase pour les variables et les champs (j'ai tendance à utiliser _camelCase pour les champs privés dans une classe)
  • PascalCase pour les méthodes, propriétés et classes

Le seul endroit où je dévie est sur les constantes et les énumérations où je préfère en fait le style Java SCREAMING_CAPS.

La base de code de mon entreprise est jonchée du style de notation pseudo-hongroise de VB6 et VBScript, sinon hongrois à part entière

  • s ou str pour les chaînes
  • i ou int pour Ints
  • d pour décimal (ou parfois double)
  • o ou obj pour tout type d'objet

Je grincer des dents chaque fois que je vois ce style de code utilisé dans le code de quelqu'un d'autre (même dans le code greenfield, pas seulement l'héritage cru), et je refuse d'utiliser ce style moi-même. J'ai évoqué la normalisation des conventions de dénomination .Net dans le passé et c'est juste ignoré - les gens qui écrivent en notation hongroise continuent de le faire, ceux d'entre nous qui ne m'aiment pas continuent à utiliser notre propre style; Je suis un peu peur que si nous faisons Normaliser (que je continue à pousser pour, mais personne ne semble d' autre aux soins), il sera sur la notation hongroise et non la méthode recommandée, puis je vais être obligé de code écrire comme ça .

Suis-je en train de faire une montagne à partir d'une taupinière à ce sujet? Ne devrais-je pas me soucier si le code est jonché d'identifiants redondants et non de noms descriptifs, et continuer à utiliser ma propre voie et pousser pour que cela devienne la norme?

c# coding-standards Wayne Molina
la source
2
Bonne question. Les conventions de dénomination sont là pour vous aider, pas pour vous gêner. Quand ils gênent (parce que leur objectif initial n'est plus pertinent), abandonnez-les.
Gary Rowe

Réponses:

7

La seule chose dont vous devriez vous soucier, c'est que vous travaillez dans une équipe où les gens ne se soucient pas de nettoyer un peu les choses. C'est triste.

Faites ce que vous faites, continuez à utiliser le style moderne et invitez les gens (mais pas à les forcer) à l'adopter également. Cela prendra du temps bien sûr. Après un certain temps, vous verrez si cela va quelque part et ce que vous pourriez faire ensuite.

PS Que diriez-vous d'organiser une réunion sur cette question et invitez toutes les personnes impliquées. Ensuite, vous obtiendrez toute leur attention, dénoterez le problème et présenterez votre approche. Cela leur donnera matière à réflexion. Peut-être que vos tentatives locales ne vous prennent pas très au sérieux.


la source
+1 Ces jours-ci, Refactor Rename est si efficace que vous remarquerez à peine l'impact de la modification.
Gary Rowe
2
Malheureusement, les gens de mon équipe n'utilisent même pas cela. Ils ont peur de renommer les choses même lorsque le nom est trompeur. Par exemple, il existe une méthode appelée SendNewCustomerEmailqui est utilisée pour envoyer toutes sortes d'e-mails, pas seulement les nouveaux e-mails des clients. Il a un commentaire d'un développeur actuel qui dit "Notez que ce nom est trompeur", mais personne n'a même envisagé de le renommer en quelque chose de plus générique et utile, et si je le fais, le gestionnaire me demandera d'expliquer pourquoi je suis en train de changer du code qui n'a pas besoin d'être changé au lieu d'ajouter de la valeur.
Wayne Molina
3

Je pense que vous devrez peut-être vous demander si la notation hongroise affecte ou non votre production / qualité personnelle, ou si elle nuit plus simplement à votre ego. Par ego, je veux dire que les choses fonctionnent généralement bien, mais vous ne voudriez jamais que quelqu'un que vous respectez de l'extérieur voie le code honteusement obsolète. Bien que je pense que cette préoccupation ait son propre mérite, vous devez la peser par rapport à la qualité / productivité qui serait prise par tous ceux qui devaient changer.

Il s'agit en quelque sorte d'une question de dette technique, car vous avez clairement raison de dire que ce style hongrois n'a aucun sens dans .Net (à l'exception des interfaces avec "I", mais c'est pour une autre fois), cependant, cela pourrait être le genre de dette technique avec laquelle votre équipe peut vivre jusqu'à ce qu'elle disparaisse naturellement .

Morgan Herlocker
la source
4
Je ne me soucie même pas du préfixe "I", et je ne l'utilise que parce qu'il évite d'avoir l'énigme Java de, disons, une interface nommée CustomerRepositoryet la classe étant CustomerRepositoryImplou similaire.
Wayne Molina
3
+1 - Il semble qu'il devrait y avoir un meilleur moyen. J'utilise de temps en temps la "lumière hongroise", mais les préfixes sont toujours liés à l'entreprise et non au type. Par exemple, tout dans la comptabilité a un côté AP et un côté AR, et ils ont souvent le même nom, comme Facture. Avoir une ARInvoice et une APInvoice me semble parfaitement raisonnable. Le hongrois n'est pas TOUT mauvais tout le temps.
Morgan Herlocker
@Wayne M Vous voudrez peut-être consulter programmers.stackexchange.com/questions/75956/…
Gary Rowe
Je ne considérerais pas vraiment cette "notation hongroise" parce que, comme vous l'avez dit, c'est une signification commerciale avec une abréviation bien définie que les gens connaissent, de la même manière que le code qui utilise XML au Xmllieu de ExtensibleMarkupLanguage. Dans un module de comptabilité, je m'attendrais à voir des objets de facture comme arInvoiceet apInvoicequi transmettent le contexte commercial, mais voir objArInvoiceou oApInvoicec'est tout simplement stupide IMO. Je suppose que ça pourrait être pire, ça pourrait être clsApInvoicepour le nom de la classe
Wayne Molina
1
@ironcode: c'est en fait ce qu'on appelle la notation hongroise des applications, contre la notation hongroise des systèmes, et c'est beaucoup mieux. Malheureusement, la plupart des gens utilisent les systèmes. en.wikipedia.org/wiki/…
Miki Watts
2

Le meilleur argument contre la notation hongroise, à côté des IDE modernes, qui ont beaucoup de méthodes pour montrer le type, la visibilité et plus de choses d'une variable avec la couleur, avec de minuscules symboles et avec des info-bulles lors de l'aspiration, est de le prendre au sérieux.

  • Encourager plus de distintcion (b) ool (f) loat (c) har (l) ong (s) hort (en conflit avec String? No: (S) tring), (v) oid.
  • Encouragez l'encodage de la visibilité. Je viens de Javaland et j'espère que cela conviendra aussi pour .net: (pri) vate, (pub) blic, (pro) tected (def) ault devrait être utilisé.
  • .net a final / const? Faites-en un préfixe! Est-ce que j'entends «volatile»?
  • Pourquoi int et long ont-ils besoin d'un préfixe, mais pas les différents objets? Ce n'est pas logique. Créez un abbrev.tab. où chaque nouvel objet obtient une abréviation distincte.
  • Les variables qui peuvent être nulles et telles, qui ne devraient jamais l'être, peuvent également être préfixées. Les gens intelligents mettent tout le DbC dans le préfixe d'une variable.

Sérieusement: lors de la refactorisation, vous pouvez changer une variable de int en long, de String en char. Vous ne devriez pas non plus avoir besoin de changer le nom.

Dans les IDE, vous obtenez les noms souvent triés dans une boîte sur le côté. triés par nom, où il est facile à trouver. Si la plupart des variables commencent par o ou i, c'est gênant pour les yeux, d'accéder à la partie significative du nom.

Les caractères supplémentaires perturbent la sémantique de la variable. Un entier «sain» obtient «i_sane», qui ressemble plus à «fou».

La notation hongroise était utile dans les langues, qui manquent d'un système de type. Vous n'en avez pas besoin, si le compilateur applique des types spécifiques. Si vous décorez votre lamento sur la notation hongroise avec un `` oui, pour les anciens programmeurs, il était logique dans le passé de l'utiliser! '', Ces anciens programmeurs pourraient être vains et préférer ne pas être identifiés comme anciens.

Mais il faut être prudent, pour que la technique fonctionne. Vous pouvez peut-être baisser la voix lorsque vous parlez de «programmeurs plus âgés», pour leur faire sentir à quel point vous êtes prudent à leur sujet, à quel point ils ont besoin de soins. Pour qu'une troisième personne dans la pièce reconnaisse, que vous essayez de cacher quelque chose, ce qui va bien sûr éveiller sa curiosité.

Utilisateur inconnu
la source
Malheureusement, je l'ai également vu eSomeEnumutilisé aussi dans des endroits; heureusement pas souvent.
Wayne Molina
2

Achetez une copie des directives de conception du cadre et déposez-la sur le bureau de votre gestionnaire (ou de celui qui contrôle le style de codage). N'oubliez pas de mettre une note post it pointant ostensiblement vers l'introduction où ils soulignent l'importance de la cohérence. Pour aller plus loin, obtenez une copie de Clean Code et placez-y un signet dans la section concernant les conventions de codage.

Michael Brown
la source
1

À certains égards, il s'agit d'un problème subjectif, et c'est l'un de ces débats de programmation (orthographe?) Que j'entretiens pendant un certain temps, puis que j'évite. Bien que je pense que la notation hongroise est un péché qui devrait être banni, je pense que la cohérence est plus importante.

Dans cette veine, je ferai de mon mieux pour convaincre une équipe d'utiliser une dénomination de variable centrée sur le domaine plutôt que des conventions de dénomination basées sur le type, mais si tout devient difficile, je reculerai pour accepter une norme de dénomination à laquelle tout le monde doit se conformer. une base de code commune.

Je ne suis pas en faveur d'une norme imposée par un groupe de normalisation, mais que les équipes logicielles développent leur propre norme et, plus important encore, s'y conforment.

rupjones
la source
1

Avec le resharper, le changement de nom des variables est si rapide que je peux annuler si rapidement les conventions de nommage considérées, que je n'ai pas à laisser les anciennes conventions mal dirigées.

Si vous ne disposez pas d'outils de refactoring, je suis d'accord avec les autres commentateurs qui ont suggéré de suivre autant que possible la convention existante de la base de code, même si elle était erronée. (jusqu'à un certain point, il existe des conventions de nommage variables qui se transformeront en générateurs de bogues si vous les laissez)

MatthewMartin
la source
0

La plupart de vos préoccupations sont valables et rendraient la vie plus facile à un nouveau développeur et probablement à votre raison. La seule convention que vous devriez tous adopter est celle des noms descriptifs. Vous devriez être en mesure de parvenir à un consensus à ce sujet sans changer radicalement les styles en fonction de leur gravité. Pour tout le reste, attendez d'être en charge ou remplacez les membres actuels par de nouveaux développeurs qui pensent et ressentent comme vous le faites.

JeffO
la source
0

Mes écarts:

  • _PublicPropertyBacker
  • _private_property_backer
  • _privateMember
  • CONSTANT_MEMBER
  • privateFunction
  • param_
  • bouton privé okBU; //etc. limiter 3 caractères
  • struct SOMESTRUCT // pour les structures pinvoke

Régions de code génériques et disposition des fichiers:

  • Membres
    • (privé | interne | protégé | public) X [statique] X [const / lecture seule]
  • Propriétés
    • (privé | interne | protégé | public) X [statique] X [en lecture seule]
  • Constructeurs
    • (privé | interne | protégé | public) X [statique]
  • Commandes // tout ce qui a un retour nul ou un retour d'état
    • (public | protégé | interne | privé) X [statique]
  • Gestionnaires d'événements / privés /
    • (Contrôle | À distance | Service | Autre) Événements
  • Fonctions // interroge l'état, ne devrait avoir aucun effet secondaire
    • (public | protégé | interne | privé) X [statique]
marque
la source