¿Cuál es la convención de nomenclatura de control recomendada para el marcado XAML?

10

Cuando se trabaja con WPF o Silverlight, ¿cómo se deben usar las convenciones de nomenclatura de control? ¿Nombra los controles en el marcado XAML? He visto muestras de proyectos en codeplex con nombres de control como "selectButton" o "btnSelect". ¿Qué recomendarías?

wpf silverlight

— Mamta D
fuente

1

Cualquiera que sea el esquema que elija, sea consistente en su aplicación.

— ChrisF

8

Microsoft tiene pautas publicadas aquí en su sitio web. La conclusión es que las convenciones de nomenclatura húngaras están fuera.

EDITAR

Para aclarar esto, Microsoft ha eliminado la notación húngara de todas sus convenciones de nomenclatura, incluidos los elementos de la interfaz de usuario. SIN EMBARGO, MS no ha documentado ninguna recomendación para los elementos de la interfaz de usuario. Hay muchos enlaces por ahí que notan esto y ofrecen sus sugerencias, pero la conclusión es que con los elementos de la interfaz de usuario, estás solo. Enlace de ejemplo .

En nuestro estándar, hemos eliminado la notación húngara y estamos usando nombres explícitos, lo que significa que un botón llamado OK se llamaría ButtonOK, un bloque de texto llamado Comentarios sería TextblockComments. La desventaja es que los nombres pueden alargarse un poco, lo positivo es que TODOS saben exactamente qué es el elemento.

Siempre que establezca lo que funciona para usted y use ese estándar de manera consistente, no puede equivocarse.

— Walter
fuente

2

Esas son pautas para nombrar miembros en bibliotecas, no elementos de UI.

— Robert Harvey

@Robert: buen punto. No me había dado cuenta de que su directriz excluía los elementos de la interfaz de usuario. Editaré mi respuesta.

— Walter

4

Por lo general, no nombro mis controles en XAML, ya que la mayoría de las veces no se usaría teniendo en cuenta que todo se establece o controla a través de enlaces. Fuente: Pete Brown

— Matthieu
fuente

El mismo artículo dice que tendrá que nombrar todos sus elementos de entrada de datos (cuadros de texto, casillas de verificación, combos) de todos modos, ya que se hará referencia a ellos en otro lugar (un almacén de datos, por ejemplo). Los elementos cromados (líneas, formas y demás) no tienen que nombrarse, y es bueno que XAML no lo obligue a hacerlo.

— Robert Harvey el

@Robert Harvey: Del artículo: "Controles interactivos de la interfaz de usuario como cuadros de texto, cuadros de lista, botones, etc. Puede escapar sin nombrarlos si está usando comandos / comportamientos y un buen patrón como MVVM, pero creo que nombrar es útil desde un punto de vista de la documentación. No es un requisito de ninguna manera, pero es útil ". Como seguí con MVVM, y no tengo que comunicar mi xaml a un diseñador para un trabajo combinado, no encontré ningún uso para estos nombres. Como mis controles son realmente simples, la documentación proporcionada por esos nombres sería exagerada. Pero estoy de acuerdo en que en una interfaz de usuario más compleja, podría ser diferente.

— Matthieu

Uso MVVM y rara vez nombro mis controles. Es bastante evidente lo que son por contexto y con el diseñador VS. Ocasionalmente pondré un comentario en el XAML.

— M. Dudley

2

No sé acerca de XAML, pero para ASP.NET antiguo normal, las convenciones que he visto son:

Buen húngaro antiguo (por ejemplo, txtFirstName, ddlState, chkAcceptsTerms)
Nombre explícito (por ejemplo, TextFirstName, DropdownState, CheckAcceptsTerms)

No estoy seguro de cuál prefiero, sinceramente. Solía ver un montón de código como # 2 pero invertido (por ejemplo, FirstNameTex, StateDropdown, AcceptsTermsCheck) pero me gusta de la otra manera, ya que agrupa los controles relacionados.

— Wayne Molina
fuente