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