WPF conventions de nommage des éléments de L'interface utilisateur
bien que notation hongroise est considéré comme une mauvaise pratique de nos jours, il est encore assez courant d'encoder le type dans le nom de éléments de l'interface utilisateur, soit en utilisant un préfixe (lblTitle,txtFirstName,...) ou un suffixe (TitleLabel, FirstNameTextBox,...).
dans mon entreprise, nous le faisons aussi, car cela rend le code écrit par des collègues (ou par vous-même il y a longtemps) plus facile à lire (d'après mon expérience). L'argument généralement soulevé contre faire cela -- vous il faut changer le nom de la variable si le type change -- n'est pas très fort, car changer le type d'un élément D'UI nécessite généralement de réécrire toutes les parties du code où il est référencé de toute façon.
donc, je pense à garder cette pratique en commençant par le développement WPF (hmmm... devrait-on utiliser le txt prefix for Textlocks or TextBoxes?). Est-il un gros désavantage que j'ai manqué? C'est ta chance de dire "Ne fais pas ça, parce que ...".
EDIT: je sais qu'avec la databinding le besoin de nommer les éléments de L'interface diminue. Néanmoins, il est parfois nécessaire, par exemple lors de l'élaboration de contrôles personnalisés...
8 réponses
personnellement, je trouve que la WPF change les règles quand il s'agit de cela. Souvent, vous pouvez vous en tirer avec peu ou pas de code derrière, donc avoir les préfixes pour distinguer les noms rend les choses plus confuses au lieu de moins de confusion.
dans les formes Windows, chaque contrôle était référencé par son nom dans le code. Avec un grand UI, la notation semi-hongroise était utile - il était plus facile de distinguer ce que vous travailliez avec.
dans la WPF, cependant, c'est un contrôle rare qui a besoin d'un nom. Lorsque vous devez accéder à un contrôle via le code, il est souvent préférable d'utiliser des propriétés ou des comportements attachés pour le faire, auquel cas vous n'avez jamais affaire à plus d'un contrôle unique. Si vous travaillez avec UserControl ou Window code-behind, j'utiliserais "Title" Et "Name" au lieu de "txtTitle", d'autant plus que maintenant vous n'aurez probablement affaire qu'à quelques commandes limitées, au lieu de toutes.
même les contrôles personnalisés ne devraient pas avoir besoin de noms, dans la plupart des cas. Vous aurez envie noms templés suivant la convention (i.e.: PART_Name), mais pas les éléments de nom x:Name pour votre UIs...
d'après mon expérience-en WPF lorsque vous changez le type de contrôle, vous n'avez normalement pas à réécrire de code à moins que vous n'ayez fait quelque chose de mal. En fait, la plupart du temps, vous ne faites pas référence aux contrôles dans le code. Oui, vous finissez par le faire, mais la majorité des références à un élément D'UI dans WPF est par d'autres éléments dans le même XAML.
et personnellement, je trouve" lblTitle, lblCompany, txtFirstName "plus difficile à lire que"Title". Je n'ai pas .intWidth and .intHeight (au revoir lpzstrName!). Pourquoi avoir .lblFirstName? Je peux comprendre TitleField ou TitleInput ou n'importe quoi d'autre, car c'est descriptif du Quoi, pas du comment.
pour moi, vouloir avoir ce type de séparation signifie normalement que mon code D'assurance - chômage essaie d'en faire trop-bien sûr, il s'agit d'un élément D'assurance-chômage, il est dans le code de la fenêtre! Si je n'ai pas affaire à du code autour d'un élément de L'interface utilisateur, Pourquoi est-ce que je le coderais ici?
j'ai comme l'utilisation d'une convention (juste une bonne idée en général), mais pour les trucs de l'INTERFACE utilisateur, je l'aime à avoir le type de contrôle à l'avant, suivi par le nom descriptif -- LabelSummary, TextSummary, CheckboxIsValid, etc.
cela semble mineur, mais la raison principale pour mettre le type en premier est qu'ils apparaîtront ensemble dans la liste Intellisense -- toutes les étiquettes ensemble, les cases à cocher, et ainsi de suite.
même D'un point de vue Winforms Je n'aime pas semi-hongrois.
le plus grand inconvénient à mon avis, et j'ai écrit beaucoup de code ui est que le hongrois rend les bogues plus difficiles à repérer. Le compilateur le récupérera généralement si vous essayez de changer la propriété cochée sur une boîte de texte, mais il ne récupérera pas quelque chose comme:
lblSomeThing.Visible = someControlsVisible;
txtWhatThing.Visible = someControlsVisible;
pbSomeThing.Visible = someControlsVisible;
je trouve ça BEAUCOUP plus facile à déboguer:
someThingLabel.Visible = someControlsVisible;
whatThingTextBox.Visible = someControlsVisible;
someThingPictureBox.Visible = someControlsVisible;
je pense aussi qu'il est beaucoup mieux de grouper un addCommentsButton avec un addCommentsTextBox que de grouper des addcommentaires BTN avec un btnCloseWindow. Quand allez-vous utiliser les deux derniers ensemble?
il est peut-être hors de propos dans WPF, mais je pense hongrois doit être évité à tout moment.
D'accord avec les autres réponses qu'il s'agit principalement de préférences personnelles, et le plus important est juste d'être cohérent.
sur la nécessité de nommer à tous, Compte tenu de la prévalence de la liaison des données... une chose que vous pourriez envisager est que si votre INTERFACE est jamais soumis à des tests automatisés. Quelque chose comme QTP trouve les éléments visuels dans une application par leur nom, et ainsi un ingénieur en automation écrivant des scripts de test appréciera grandement quand des choses comme des onglets, des boutons, etc. (tout contrôle interactif) sont tous bien son nom.
dans WPF vous pratiquement jamais besoin (ou même vouloir) de nommer vos contrôles. Donc, si vous utilisez les meilleures pratiques du FPF, peu importe ce que vous faites!--2--> nommer vos contrôles si vous aviez une raison de les nommer.
dans les rares cas où vous voulez réellement donner un nom à un contrôle (par exemple pour un ElementName= ou TargetName= reference), je préfère choisir un nom décrivant basé sur le but du nom, par exemple:
<Border x:Name="hilightArea" ...>
...
<DataTrigger>
...
<Setter TargetName="hilightArea" ...
Je préfixe n'importe quel nom d'interface utilisateur avec deux underscores, comme dans __ donc il est classé avant les autres propriétés lors du débogage. Quand J'ai besoin D'utiliser IntelliSense pour trouver un contrôle, je tape juste __ et une liste des écrans de contrôle. Ceci continue la convention de nommage du préfixe d'un simple underscore à des variables de niveau de module, comme dans int _id;.
vous pouvez utiliser le site officiel de Microsoft pour les conventions de nommage Visual Basic 6 control, et peut-être le combiner avec les conventions de nommage c# recommandées. Il est très spécifique, est largement utilisé par les développeurs en C# ainsi que pour les noms de contrôle, et peut encore être utilisé dans un contexte WPF ou Windows Forms.
Visual Basic 6 contrôle des conventions de nommage: Conventions De Nommage Des Objets
C# recommandé conventions de nommage en général: Dénomination Générale Conventions