Quelle est la convention de dénomination de contrôle recommandée pour le balisage XAML?

10

Lorsque vous travaillez avec WPF ou Silverlight, comment utiliser les conventions de dénomination des contrôles? Nommez-vous les contrôles dans le balisage XAML? J'ai vu des échantillons de projets chez codeplex avec des noms de contrôle tels que "selectButton" ou "btnSelect". Que recommanderais-tu?

wpf silverlight

— Mamta D
source

1

Quel que soit le schéma que vous choisissez - soyez cohérent dans votre application.

— ChrisF

8

Microsoft a publié des directives ici sur leur site web. L'essentiel est que les conventions de dénomination hongroises sont sorties.

ÉDITER

Pour rendre cela plus clair, Microsoft a supprimé la notation hongroise de toutes ses conventions de dénomination, y compris les éléments d'interface utilisateur. CEPENDANT, MS n'a documenté aucune recommandation pour les éléments d'interface utilisateur. Il y a beaucoup de liens qui notent cela et offrent leurs suggestions, mais l'essentiel est qu'avec les éléments d'interface utilisateur, vous êtes seul. Exemple de lien .

Dans notre standard, nous avons abandonné la notation hongroise et utilisons une dénomination explicite, ce qui signifie qu'un bouton appelé OK serait nommé ButtonOK, un bloc de texte appelé Commentaires serait TextblockComments. L'inconvénient est que les noms peuvent devenir assez longs, le positif est que TOUT LE MONDE sait exactement ce qu'est l'élément.

Tant que vous établissez ce qui fonctionne pour vous et utilisez cette norme de manière cohérente, vous ne pouvez pas vous tromper.

— Walter
source

2

Ce sont des directives pour nommer les membres dans les bibliothèques, pas les éléments d'interface utilisateur.

— Robert Harvey

@Robert - bon point. Je n'avais pas remarqué que leur directive excluait les éléments d'interface utilisateur. Je vais modifier ma réponse.

— Walter

4

Je ne nomme généralement pas mes contrôles en XAML, car il serait, la plupart du temps, inutilisé étant donné que tout est défini ou contrôlé via des liaisons. Source: Pete Brown

— Matthieu
source

Le même article dit que vous devrez de toute façon nommer tous vos éléments de saisie de données (zones de texte, cases à cocher, combos), car ils seront référencés ailleurs (un magasin de données, par exemple). Les éléments chromés (lignes, formes et autres) n'ont pas besoin d'être nommés, et c'est bien que XAML ne vous y oblige pas.

— Robert Harvey

@Robert Harvey: De l'article: "Contrôles d'interface utilisateur interactifs comme TextBoxes, ListBoxes, Buttons etc. Vous pouvez vous en tirer sans les nommer si vous utilisez des commandes / comportements et un bon modèle comme MVVM, mais je trouve que le nommage est utile à partir d'un point de vue de la documentation. Pas une exigence en aucune façon, mais utile. ". Comme je suis allé avec MVVM, et que je n'ai pas à communiquer mon xaml à un concepteur pour le travail de mélange, je n'ai trouvé aucune utilité pour ces noms. Mes contrôles étant vraiment simples, la documentation fournie par ces noms serait exagérée. Mais je suis d'accord que sur une interface utilisateur plus complexe, cela pourrait être différent.

— Matthieu

J'utilise MVVM et je nomme rarement mes commandes. Il est assez évident de savoir ce qu'ils sont par contexte et avec le concepteur VS. Parfois, je mettrai un commentaire dans le XAML.

— M. Dudley

2

Je ne connais pas XAML mais pour les anciens ASP.NET classiques, les conventions que j'ai vues sont:

Bon vieux hongrois (par exemple txtFirstName, ddlState, chkAcceptsTerms)
Dénomination explicite (par exemple TextFirstName, DropdownState, CheckAcceptsTerms)

Je ne sais pas ce que je préfère, honnêtement. J'avais l'habitude de voir beaucoup de code comme # 2 mais inversé (par exemple FirstNameTex, StateDropdown, AcceptsTermsCheck) mais j'aime l'autre sens car il regroupe les contrôles associés.

— Wayne Molina
source