Convention de nommage pour les contrôles

Microsoft a des directives de nommage sur son site Web ( ici ). J’ai aussi le livre Framework Design Guidelines.

Ce que je n’ai pas pu trouver, c’est un guide sur les contrôles de nommage.

Par exemple, un bouton, lorsqu’il est déposé dans un formulaire, obtient le nom de type + numéro, camel-cased comme nom par défaut, tel que “button1”.

Voici ce que je fais: je supprime le numéro et ajoute une description significative après. Par exemple, “buttonDelete” ou “buttonSave”.

De cette façon, vous n’avez pas besoin de conserver une grande liste de contrôles et leurs noms abrégés dans un guide quelque part.

Êtes-vous d’accord?

Je n’ai pas de convention en tant que telle, mais j’essaie d’être très large avec la partie “type” du nom. Par exemple, Button, Link Link, Image Button ont tendance à s’appeler ‘quelque choseButton’. Les listes déroulantes et les listes de boutons radio se terminent toutes par «quelque chose de sélecteur». Les zones de texte et les calendriers sont “quelque chose d’Input”. De cette façon, j’ai une idée approximative de la sorte de contrôle sans que le nom soit lié à la mise en œuvre réelle. Si je décide de remplacer un groupe de boutons d’option par une liste déroulante, inutile de le renommer!

Mise en garde: Les éléments suivants sont davantage destinés au développement WinForm / WPF . Pasortingck Peters a souligné à juste titre que la gestion des contrôles ASP.NET pose des problèmes de performances en termes de bande passante et de performances.

Il n’y a pas vraiment de norme ici, et je pense que c’est parce que c’est l’un des scénarios de nommage les plus arbitraires . Dans la plupart des cas, les contrôles sont privés de la classe et utilisés légèrement dans les gestionnaires d’événements.

Comme d’autres répondeurs, moi aussi, je passais beaucoup de temps à “réparer” les noms de contrôle . Je ferais des choses comme “btnSave”, “tbxName” (tbx pour TextBox), etc. Cependant, en expliquant mon schéma à quelqu’un d’autre, j’ai réalisé à quel point c’était arbitraire. Est-ce que “cbx” est une ComboBox ou une case à cocher?

Cela m’a amené à réexaminer ce que le concepteur fait automatiquement et à réaliser que je peux nommer clairement, systématiquement et rapidement les commandes si je laisse le concepteur effectuer le travail. C’est en fait très similaire à la suggestion de l’affiche de la question:

Je remplace le numéro de contrôle par la sémantique du contrôle. Ainsi, “button1” (valeur par défaut du concepteur) sera “buttonSave” et “listBox3” deviendra “listBoxWidgets”. S’il n’y a qu’un seul contrôle de ce type, je supprime simplement le numéro : “errorProvider1” devient “errorProvider”.

Alors, comment est-ce mieux?

  • Fixer méticuleusement les noms de variable est une perte de temps si c’est une variable interne
  • Votre schéma de dénomination sera probablement ambigu s’il raccourcit un tas de choses (CheckBox ou ComboBox)
  • Le concepteur donne un bon sharepoint départ cohérent, facile (et rapide) à spécialiser
  • La longueur du nom de la variable est sans importance lorsque vous utilisez Intellisense
  • Les noms de contrôle se groupent bien et intuitivement (dans Intellisense) lorsqu’ils sont précédés de leur type. Lorsque vous avez 15 zones de texte sur votre formulaire, vous vous souvenez tout d’abord que vous voulez une zone de texte, tapez “textBox”, puis choisissez le nom dans la liste.
  • Toute personne qui ne connaît pas votre “schéma” peut le voir immédiatement et l’adopter plus rapidement que tout le rest.
  • Il est TRÈS rapide de fournir des noms de contrôle utiles … très peu de maniement clavier / souris pour le faire … donc productivité élevée avec des résultats intuitifs. Qu’est-ce que ne pas aimer?

PS Cela tend à poser une question à Bikeshed, mais comme je peux peindre un bikeshed, je me suis lancée dans la discussion. 😉

En voici quelques unes:

frm Form mnu Form menu cmd Command button chk Check button opt Radio button lbl Text label txt Text edit box pb Picture box pic Picture lst List box cbo Combo box tmr Timer 

Une liste plus longue se trouve dans INFO: Objet. Conventions de dénomination de la notation hongroise pour VB .

Je ne fais pas WinForm pendant un bon bout de temps mais ce que j’ai fait était deux choses.

  • décochez la case “générer un membre” (ou quelle que soit son appellation) pour des éléments tels que les libellés, etc. En gros, veillez à ne conserver dans le champ que les éléments dont j’ai besoin.
  • pour ceux dont j’ai besoin, définissez un nom descriptif. Si nécessaire, ajoutez le nom du contrôle (par exemple, saveButton). Si je n’ai pas envie d’append un nom de contrôle ajoute une valeur, je ne voudrais pas append le «Bouton» et laisser le nom simplement comme «enregistrer».

Fondamentalement, la plupart du temps, je ne créerais pas de membre du bouton Enregistrer. (Si vous avez une logique de sauvegarde, vous ne pouvez toujours avoir que le gestionnaire d’événements OnSaving abonné à l’événement Click du bouton).

https://msdn.microsoft.com/en-us/library/ms233630(v=vs.110).aspx

Oui changer ces noms

Pour moi:

  • Button btnDescription

  • TextBox txtDescription

  • ComboBox cboDescription

etc…

La programmation d’interface graphique devient la règle quand il s’agit de conventions de toutes sortes. Voir ma réponse à une autre question pour les directives que j’utilise pour nommer.

Oui, vous avez besoin d’identifiants significatifs pour toute variable – control ou pas – les noms par défaut ne sont que parce que votre IDE ne sait rien de votre domaine problématique et ne peut donc pas toujours “deviner” un meilleur nom.

Je suis probablement l’une des dernières personnes à utiliser encore la notation hongroise. Je connais cet argument selon lequel l’EDI peut vous dire le type de variable, mais cela ne m’aide pas lorsque je code dans Notepad ++ ou que je regarde une impression …. de toute façon, j’utilise les options “btnSave”, “cbOptions”, “txtFirstName”, “lblTitle”, “ddlCardType”, etc … J’aime pouvoir jeter un coup d’œil sur le code et savoir ce que je cherche sans chercher de déclaration ou survoler une variable pour obtenir son type de données à partir du fichier. IDE.

Je crois que la pensée actuelle désapprouve l’inclusion du type de contrôle dans le nom. Je serais enclin à les traiter comme un autre object que j’utilise et à suivre la même convention d’appellation.

Utilisez des noms significatifs, cela va sans dire 🙂 Cependant, à la fin de la journée, si votre convention de noms a toujours un sens pour vous lorsque vous revisitez votre code des mois plus tard, je le maintiendrais probablement.

Oui, je suis tout à fait d’accord (mais je l’ai renommé en ButtonDelete), les noms en minuscules sont donc pour les variables dans mon cas 🙂

Personnellement, je pense que tant que vous êtes cohérent, vous ne rencontrerez aucun problème, même si quelqu’un d’autre lit votre code.

Je ne suis pas sûr, mais je pense que l’atsortingbution de nom de contrôle dans Windows Forms est l’un des seuls endroits où je peux voir une utilisation de la notation hongroise . Donc je pense que tu es bon.

C’est ce que nous utilisons

En bref, nous préfixons les contrôles avec une abréviation du contrôle. c’est à dire

Boutons = btnDelete, btnSubmit, btnReturn

Textboxes = txtUsername, txtPassword etc.

De cette façon, en tapant l’abréviation, vous obtenez toutes les commandes similaires lorsque vous avez fini de taper l’abréviation, c’est-à-dire que tapez btn et intellisense listera tous les boutons que vous avez ajoutés jusqu’à présent.