Conventions de dénomination variables? [fermé]

Je viens de commencer à utiliser ReSharper (pour C #) et j'aime un peu son détecteur d'odeurs de code, il me montre certaines choses sur mon écriture que je voulais corriger il y a longtemps (principalement les conventions de dénomination des variables).

Cela m'a amené à reconsidérer certaines de mes conventions d'appellation pour les méthodes et les variables d'instance. ReSharper suggère que la variable d'instance soit en minuscule et commence par un trait de soulignement. Pendant un certain temps, je voulais faire en sorte que toutes mes variables locales réduisent la casse du chameau, mais le trait de soulignement est-il nécessaire? Trouvez-vous cela confortable? Je n'aime pas cette convention mais je ne l'ai pas encore essayée, qu'en pensez-vous?

La deuxième chose qu'il m'a incité à réévaluer est mes conventions de dénomination pour les gestionnaires d'événements GUI. J'utilise généralement la norme VS de ControlName_Action et mes contrôles utilisent généralement la notation hongroise (comme suffixe, pour aider à clarifier dans le code ce qui est visible pour l'utilisateur et ce qui ne l'est pas lorsqu'il s'agit d'une variable de nom similaire), donc je me retrouve avec OK_btn_Click ( ), qu'en pensez-vous? Dois-je succomber à la convention ReSharper ou existe-t-il d'autres options également valables?

Vous pouvez modifier ReSharper pour utiliser le schéma de convention de dénomination que vous utilisez. Il est assez flexible, y compris la personnalisation des gestionnaires d'événements, des champs, des propriétés, des méthodes avec différents niveaux d'accessibilité, etc.

Ne laissez pas l'outil définir vos normes - utilisez-le pour appliquer les vôtres.

Mise à jour: Cela dit, au travail, nous utilisons principalement des minuscules de chameau pour la plupart des choses privées - variables, champs et arguments. Cas de chameau supérieur pour les noms de méthode, les constantes et les propriétés. Les gestionnaires d'événements sont nommés en fonction de l'action qu'ils représentent, plutôt que de quelque chose de spécifique au contrôle - par exemple HandleCustomerContinue plutôt que HandleContinueButtonClick. J'ai essayé le schéma par défaut de ReSharper pendant un certain temps et en fait cela ne me dérange pas, je ne suis vraiment pas dérangé de toute façon.

Par rapport à

mais le trait de soulignement est-il nécessaire? le trouvez-vous confortable?

Une chose que j'aime beaucoup dans l'utilisation du trait de soulignement, c'est qu'il réduit considérablement l'utilisation de "ceci".

Considérer:

public void Invoke(int size) {
    _size = size;
}

sans le soulignement, il faudrait écrire:

public void Invoke(int size) {
    this.size = size;
}

ce qui introduit potentiellement l'erreur subtile de:

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

De plus, l'achèvement du code est plus propre car en attachant simplement le trait de soulignement, vous obtenez une liste des seuls champs privés, alors qu'avec "ceci", vous obtenez une liste de tout.

Par rapport à

utilisent généralement la notation hongroise

le Framework Design Guidelines: Conventions, Idoms, and Patterns for Reusable .NET bibliothèques dit:

NE PAS utiliser la notation hongroise

Laissant peu de place à l'ambiguïté:)

La cohérence est vraiment la clé. Cela et la clarté, c'est-à-dire ne soyez pas cryptique ou n'essayez pas de sauvegarder la frappe en abrégeant tout. Intellisense est votre économiseur de frappe, pas des noms cryptés (mais courts!).

En C #, le démarrage d'un nom protégé ou public avec un trait de soulignement est contraire à la spécification de langage commun. C'est correct uniquement en cas de membres privés.

Depuis MSDN:

Pour interagir pleinement avec d'autres objets, quelle que soit la langue dans laquelle ils ont été implémentés, les objets doivent exposer aux appelants uniquement les fonctionnalités communes à toutes les langues avec lesquelles ils doivent interagir. Pour cette raison, la Common Language Specification (CLS), qui est un ensemble de fonctionnalités linguistiques de base nécessaires à de nombreuses applications, a été définie.

Voir: http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Ici, vous pouvez lire l'avertissement sur le trait de soulignement:

Les noms d'élément commençant par un trait de soulignement (_) ne font pas partie de la spécification CLS (Common Language Specification), donc le code compatible CLS ne peut pas utiliser un composant qui définit de tels noms. Cependant, un trait de soulignement à toute autre position dans un nom d'élément est conforme CLS.

Voir: http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

Les membres protégés posent problème car vous pouvez hériter d'une classe écrite dans une autre langue.

Mais ce n'est peut-être pas un problème dans votre cas si vous n'avez pas besoin de code compilant CLS.

J'aime les traits de soulignement. Vous savez à première vue que la variable est un membre de la classe et privée.

Bien sûr, l'IDE peut vous le dire lorsque vous passez la souris dessus, mais le "premier coup d'œil" est imbattable. Vous savez ce qu'est une variable locale et ce qu'est une variable membre avec vos yeux seuls. Aucun défilement ou survol de la souris requis.

Vous pouvez utiliser le mot clé "this" mais _ est plus court pour une meilleure numérisation horizontale. Les noms descriptifs sont généralement souhaités, mais lorsque quelque chose est une convention établie, il vaut mieux avoir 1 caractère. par exemple, en utilisant la lettre i comme index lors de la boucle d'un tableau. Comme il s'agit d'une convention établie selon laquelle i est un index, vous bénéficiez de la possibilité de numérisation sans l'inconvénient de vous demander ce que signifie «i».

Je suis généralement d'accord avec ce que disent les autres, mais en ce qui concerne les outils et les chaînes d'outils, je suis paresseux et aime la vie facile. Je trouve que la vie est souvent plus facile à faire comme ils le suggèrent. Les raisons sont

• C'est plus facile à installer (allez simplement avec les valeurs par défaut, même je peux appuyer sur Entrée 20 fois et le faire démarrer)
• Les bogues ont généralement été résolus à partir des paramètres par défaut, souvent c'est la configuration ésotérique que j'ai mise en place qui expose un défaut pour la première fois
• Le vendeur de la chaîne d'outils en sait probablement plus que moi, c'est pourquoi ils l'ont fait pour une raison. Qui suis-je pour décider que les experts ont tort (je les considère comme des experts, car j'ai acheté leur outil)
• Vous n'aurez jamais à défendre le choix des vendeurs par un Manager - "C'est ce qu'ils recommandent"
• Le nouveau gars ne vous embêtera pas avec "pourquoi" et "C'est mieux comme ça" - Quand chaque réponse est "parce qu'ils ont décidé ..."

Donc, je pense que si vous pouvez trouver une raison valable de reconfigurer les outils sur lesquels vous venez de dépenser une fortune, faites-le par tous les moyens. Si vous ne pouvez pas justifier le changement, ne le faites pas.

Gardez à l'esprit que chaque changement a un coût permanent (réel et caché) à maintenir. Moins il y en a, plus le coût est faible. Par exemple - ce nouveau gars que j'ai mentionné - aucun changement ne signifie qu'il peut lire leur manuel. Reconfigurez - vous devez rédiger l'addendum, le ranger avec d'autres trucs, le retirer et le faire lire après avoir lu leur manuel. Ce n'est peut-être pas un problème pour un magasin de 2 hommes, mais qu'en est-il d'un magasin de 100 hommes?

Les deux règles que vous demandez, soulignent au début des noms de champs privés et les noms de méthode sont généralement considérés comme la norme dans les cercles de développement C #. En s'adaptant à ces conventions, votre code sera immédiatement plus compréhensible pour les autres développeurs, car c'est l'état d'esprit dans lequel ils sont habitués à fonctionner.

Le suffixe de Label, RadioButton, etc. pour vos commandes est également généralement considéré comme la norme. Il existe souvent plusieurs contrôles pour un même concept (par exemple, une étiquette et une zone de texte), et ce suffixe est très utile. La vraie notation hongroise a été abandonnée il y a longtemps car elle a été bâtie en quelque chose qui n'exprime pas son intention d'origine, qui était le contexte de la variable et non le type, la taille, etc.

Dans mon cas, l'utilisation de camelcase et de traits de soulignement aide à nommer (lire: long) les noms de variables et à compléter le code. Je ne sais pas trop comment fonctionne l'auto-complétion de Visual Studio mais dans QtCreator et dans une moindre mesure, Eclipse, on peut taper, par exemple

sDI

et l'ont étendu à

someDescriptiveIdentifier

Économise un peu de frappe au cas où vous auriez des noms comme

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

que j'ai tendance à produire en "mode de nommage descriptif".

À l'aide de soulignements, je peux déterminer le nom que je souhaite compléter automatiquement

someDescriptiveIdentifier

ou

_someDescriptiveClassMember

J'espère que mon explication est assez claire :)