WPF élément de l'INTERFACE utilisateur des conventions de nommage

Bien que La notation hongroise est considéré comme une mauvaise pratique de nos jours, il est encore assez commun pour coder le type au nom de éléments de l'interface utilisateur, soit à l'aide d'un préfixe (lblTitle, txtFirstName, ...) ou un suffixe (TitleLabel, FirstNameTextBox, ...).

Dans ma société, nous avons aussi le faire, car il rend le code écrit par le co-travailleurs (ou par vous-même il y a longtemps) plus facile à lire (dans mon expérience). L'argument généralement soulevée à l'encontre de faire cela, vous avez à changer le nom de la variable si les changements de type de -- n'est pas très forte, car changer le type d'un élément de l'INTERFACE utilisateur nécessite généralement la réécriture de toutes les parties du code ont été référencé de toute façon.

Donc, je suis en train de penser à propos de l'observance de cette pratique lors du démarrage avec WPF développement (hmmm... doit-on utiliser le txt préfixe pour TextBlocks ou des zones de texte?). Est-il un gros désavantage que j'ai manqué? Ceci est votre chance de dire "ne faites pas ceci, parce que ...".

EDIT: je sais qu'avec la liaison de données, le besoin de nommer les éléments de l'INTERFACE utilisateur diminue. Néanmoins, il est parfois nécessaire, par exemple lors de l'élaboration de contrôles personnalisés...

  • Jamais réellement nécessaire de nommer un TextBlock, de sorte que txt problème peut être un point discutable. En Fait, vous ne devez jamais le nom de n'importe quoi, si vous avez besoin d'y accéder à partir du code ou de la sorte. Depuis plus de WPF INTERFACE utilisateur est conduit par la liaison de données et déclarées dans le code XAML ce qui réduit considérablement le besoin d'avoir tous les contrôle nommé.
  • Vous aurez également besoin de les nommer si d'autres UIElements lier à l'aide de ElementName de liaison.
InformationsquelleAutor Heinzi | 2009-11-16
  1. 32

    Personnellement, je trouve que WPF change les règles quand il s'agit de cela. Souvent, vous pouvez vous en sortir avec peu ou pas de code derrière, afin d'avoir les préfixes pour les distinguer des noms rend les choses plus confuses au lieu de moins à confusion.

    En Windows Forms, chaque contrôle a été référencée par un nom de code. Avec une grande INTERFACE utilisateur, le semi-notation hongroise a été utile - il était plus facile de distinguer ce que vous travailliez.

    Dans WPF, cependant, il est rare de contrôle qui a besoin d'un nom. Lorsque vous devez accéder à un contrôle par un code, il est souvent préférable d'utiliser des propriétés attachées ou des comportements à le faire, dans ce cas, vous êtes de ne jamais traiter avec plus d'un seul contrôle. Si vous travaillez dans le UserControl ou de la Fenêtre de code-behind, je venais de l'utilisation de "Titre" et "Nom" au lieu de "txtTitle", surtout depuis maintenant, vous aurez probablement seulement être en contact avec un peu limitée des contrôles, au lieu de tous les.

    Même des contrôles personnalisés ne devriez pas besoin de noms, dans la plupart des cas. Vous aurez envie basées sur des modèles de noms de convention ci-après (c'est à dire: Nom_pièce), mais pas réel x:Name des éléments pour votre Isu...

    InformationsquelleAutor Reed Copsey
  2. 13

    Dans mon expérience, WPF lorsque vous changez le type de contrôle, vous n'avez normalement pas avoir à réécrire le code, sauf si vous avez fait quelque chose de mal. En fait, la plupart du temps, vous ne faites pas référence à des contrôles dans le code. Oui, tu finis par le faire, mais la majorité des références à un élément de l'INTERFACE utilisateur dans WPF est par d'autres éléments du même code XAML.

    Et personnellement, je trouve "lblTitle, lblCompany, txtFirstName" plus difficile à lire que le "Titre de propriété". Je n'ai pas .intWidth et .intHeight (au revoir lpzstrName!). Pourquoi avoir .lblFirstName? Je peux comprendre TitleField ou TitleInput ou que ce soit un peu plus que ça descriptif de la ce que, pas le comment.

    Pour moi, qui souhaitent avoir ce type de séparation signifie normalement mon code de l'INTERFACE utilisateur est en train d'essayer d'en faire trop - bien sûr, il ne traite qu'avec un élément de l'INTERFACE utilisateur, c'est dans le code de la fenêtre! Si je ne suis pas traiter avec le code autour d'un élément de l'INTERFACE utilisateur, pourquoi dans le monde serait-je coder ça ici?

    InformationsquelleAutor Philip Rieck
  3. 7

    J'aime à l'aide 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.

    Il semble mineur, mais la principale raison pour mettre le premier type est qu'ils vont apparaître dans la liste Intellisense -- toutes les étiquettes, des cases à cocher, et ainsi de suite.

    • D'accord avec tout ce que tu dis, je fais la même chose pour les mêmes raisons.
    • Si vous vous trouvez à l'aide d'Intellisense pour le type de contrôle des noms de code sur une base régulière, cela veut probablement dire que vous êtes en utilisant WPF comme si c'était "mauvais vieux WinForms" et de ne pas profiter pleinement des fonctionnalités avancées de WPF (liaison de données, des modèles, etc).
    • Je ne conteste pas que WPF est un autre modèle d'utilisation de "mauvais vieux Winforms", mais j'ai seulement besoin de regarder pour un nom de contrôle une fois pour apprécier une convention qui les rend faciles à trouver.
    • Cela peut être une douleur, parfois, trop - je veux trouver le Titre, j'ai donc essayer TextTi... oups. C'est un combo? ComboTitl... euh, non. Oh, nous n'autorisons deux - peut-être un bouton radio? RadioTitle! aha!
    InformationsquelleAutor Jeff Donnici
  4. 4

    Même à partir d'un Winforms point de vue je n'aime pas les demi-hongrois.

    Le plus grand inconvénient à mon avis, et j'ai écrit BEAUCOUP de code de l'interface utilisateur est que le hongrois fait des bugs plus difficile à repérer. Le compilateur va généralement chercher si vous essayez de modifier la propriété checked sur une zone de texte, mais il ne sera pas ramasser 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 que c'est beaucoup mieux pour un groupe addCommentsButton avec un addCommentsTextBox que le groupe a btnAddComments avec un btnCloseWindow. Quand êtes-vous jamais allons utiliser les deux derniers ensemble?

    Aussi loin que de trouver le contrôle je veux, je suis d'accord avec Philippe Rieck. Je veux souvent pour traiter toutes les commandes associées à une logique particulière concept (comme le titre, ou d'ajouter des commentaires). J'ai à peu près jamais l'envie de trouver de l'une quelconque ou toutes les zones de texte qui se trouve être sur ce contrôle.

    C'est peut-être hors de propos dans WPF, mais je pense que le hongrois doit être évité à tout moment.

    InformationsquelleAutor Justin Doyle
  5. 3

    D'accord avec les autres réponses, c'est principalement de préférence personnelle, et le plus important est d'être cohérent.

    Sur la nécessité de nommage à tous, compte tenu de la prévalence de la liaison de 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 son Nom, et donc d'un ingénieur en automatisme de l'écriture des scripts de test apprécieront grandement lorsque les choses comme les onglets, les boutons etc. (tout contrôle interactif) sont tous bien son nom.

    InformationsquelleAutor Lyall
  6. 1

    Dans WPF on a pratiquement jamais besoin (ou même vouloir) au nom de vos commandes. Donc, si vous êtes en utilisant WPF bonnes pratiques, il n'a pas d'importance ce que vous serait nom de vos contrôles si vous aviez une raison de les nommer.

    Sur les rares occasions où vous voulez vraiment donner à un contrôle d'un nom (par exemple pour un ElementName= ou TargetName= référence), je préfère choisir un nom décrivant la fonction de l'objet pour le nom, par exemple:

    <Border x:Name="hilightArea" ...>
   ...

<DataTrigger>
   ...
   <Setter TargetName="hilightArea" ...
    InformationsquelleAutor Ray Burns
  7. 1

    Je préfixe de l'utilisateur nom de l'interface avec deux caractères de soulignement, comme dans __ de sorte qu'il est trié avant les autres propriétés lors du débogage. Quand j'ai besoin d'utiliser IntelliSense pour trouver un contrôle, je viens de type __ et une liste de commandes affiche. Cela continue la convention de nommage de la préfixation d'un seul trait de soulignement pour les variables de niveau module, comme dans int _id;.

    InformationsquelleAutor AMissico
  8. 1

    Vous pouvez utiliser le site internet officiel de Microsoft Visual Basic 6 contrôle des conventions de nommage, et peut-être de le combiner avec le recommandé C# conventions de nommage. C'est très spécifique, est largement utilisé par les développeurs en C# ainsi que pour le contrôle des noms, et peut encore être utilisé dans un WPF ou Windows Forms contexte.

    Visual Basic 6 contrôle des conventions de nommage: L'Objet Des Conventions De Nommage

    C# recommandé conventions de nommage en général: Générale Des Conventions De Nommage

    InformationsquelleAutor Mathias Lykkegaard Lorenzen