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

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?

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.

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 .

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

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.

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

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)

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.

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]