studio - Convenciones de nomenclatura de elementos UI de WPF
visual studio wpf (8)
De acuerdo con las otras respuestas, es principalmente una preferencia personal, y lo más importante es ser consistente.
En cuanto a la necesidad de asignar nombres, dada la prevalencia del enlace de datos ... una cosa que debería considerar es si su interfaz de usuario está sujeta a pruebas automáticas. Algo así como QTP encuentra los elementos visuales en una aplicación por Nombre, por lo que un ingeniero de automatización que escribe guiones de prueba apreciará mucho cuando cosas como pestañas, botones, etc. (cualquier control interactivo) estén bien nombrados.
Aunque la notación húngara se considera una mala práctica en la actualidad, todavía es bastante común codificar el tipo en el nombre de los elementos de la interfaz de usuario , ya sea utilizando un prefijo ( lblTitle , txtFirstName , ...) o un sufijo ( TitleLabel , FirstNameTextBox , .. .).
En mi empresa, también hacemos esto, ya que hace que el código escrito por los compañeros de trabajo (o por usted mismo hace mucho tiempo) sea más fácil de leer (en mi experiencia). El argumento que generalmente se presenta para no hacer esto, tiene que cambiar el nombre de la variable si el tipo cambia, no es muy sólido, ya que cambiar el tipo de un elemento de la interfaz de usuario generalmente requiere volver a escribir todas las partes del código donde se hace referencia. .
Entonces, estoy pensando en mantener esta práctica al comenzar con el desarrollo de WPF (hmmm ... ¿deberíamos usar el prefijo txt para TextBlocks o TextBoxes?). ¿Hay alguna gran desventaja que haya pasado por alto? Esta es tu oportunidad de decir "No hagas esto, porque ...".
EDITAR: Sé que con el enlace de datos, la necesidad de nombrar elementos de IU disminuye. Sin embargo, a veces es necesario, por ejemplo, al desarrollar controles personalizados ...
En WPF prácticamente nunca necesitas (o incluso quieres) nombrar tus controles. Entonces, si está usando las mejores prácticas de WPF, no importará cómo nombre sus controles si tuviera una razón para nombrarlos.
En esas raras ocasiones en las que realmente desea asignar un nombre a un control (por ejemplo, para ElementName = o TargetName = reference), prefiero elegir un nombre que describa según el propósito del nombre, por ejemplo:
<Border x:Name="hilightArea" ...>
...
<DataTrigger>
...
<Setter TargetName="hilightArea" ...
En mi experiencia, en WPF, cuando cambia el tipo de control, normalmente no tiene que volver a escribir ningún código a menos que haya hecho algo incorrecto. De hecho, la mayoría de las veces no hace referencia a los controles en el código. Sí, terminas haciéndolo, pero la mayoría de las referencias a un elemento de UI en WPF son de otros elementos en el mismo XAML.
Y personalmente, encuentro que "lblTitle, lblCompany, txtFirstName" es más difícil de leer que "Title". No tengo .intWidth y .intHeight (¡adiós lpzstrName!). ¿Por qué tener .lblFirstName? Puedo entender TitleField o TitleInput o lo que sea más, ya que describe el qué, no el cómo.
Para mí, desear tener ese tipo de separación normalmente significa que mi código de UI está tratando de hacer demasiado. Por supuesto, se trata de un elemento de UI, ¡está en el código de la ventana! Si no estoy tratando con el código alrededor de un elemento UI, ¿por qué en el mundo lo estaría codificando aquí?
Incluso desde una perspectiva de Winforms no me gusta el semi-húngaro.
La mayor desventaja en mi opinión, y he escrito MUCHO código de interfaz de usuario es que el húngaro hace que los errores sean más difíciles de detectar. El compilador generalmente lo recogerá si intentas cambiar la propiedad marcada en un cuadro de texto, pero no recogerá algo como:
lblSomeThing.Visible = someControlsVisible;
txtWhatThing.Visible = someControlsVisible;
pbSomeThing.Visible = someControlsVisible;
Me parece mucho más fácil de depurar:
someThingLabel.Visible = someControlsVisible;
whatThingTextBox.Visible = someControlsVisible;
someThingPictureBox.Visible = someControlsVisible;
También creo que es mucho mejor agrupar un addCommentsButton con un addCommentsTextBox que agrupar un btnAddComments con un btnCloseWindow. ¿Cuándo vas a usar los dos últimos juntos?
En cuanto a encontrar el control que quiero, estoy de acuerdo con Philip Rieck. A menudo quiero tratar todos los controles que se relacionan con un concepto lógico particular (como el título o agregar comentarios). Casi nunca quiero encontrar uno o todos los cuadros de texto que están en este control.
Es posible que sea irrelevante en WPF, pero creo que el húngaro debería evitarse en todo momento.
Me gusta usar una convención (solo una buena idea en general), pero para la IU me gusta tener el tipo de control en la parte delantera, seguido del nombre descriptivo: LabelSummary, TextSummary, CheckboxIsValid, etc.
Suena menor, pero la razón principal para poner el tipo primero es que aparecerán juntos en la lista de Intellisense: todas las etiquetas juntas, casillas de verificación, etc.
Personalmente, encuentro que WPF cambia las reglas cuando se trata de esto. A menudo, puede salirse con poco o ningún código detrás, por lo que tener los prefijos para distinguir los nombres hace que las cosas sean más confusas en lugar de menos confusas.
En Windows Forms, cada control fue referenciado por su nombre en el código. Con una interfaz de usuario grande, la notación semihúngara era útil: era más fácil distinguir con qué estaba trabajando.
En WPF, sin embargo, es un control raro que necesita un nombre. Cuando tiene que acceder a un control a través de un código, a menudo es mejor usar propiedades o comportamientos adjuntos para hacerlo, en cuyo caso nunca se trata de más de un solo control. Si está trabajando en el código de control de UserControl o en la ventana, solo usaría "Título" y "Nombre" en lugar de "txtTitle", especialmente porque ahora probablemente solo estará tratando con unos pocos controles limitados, en lugar de de todos ellos
Incluso los controles personalizados no deberían necesitar nombres, en la mayoría de los casos. Querrá nombres de plantilla siguiendo la convención (es decir: PART_Name), pero no x real: Elementos de nombre para sus interfaces de usuario ...
Prefijo cualquier nombre de interfaz de usuario con dos guiones bajos, como en __ por lo que se clasifica antes que otras propiedades cuando se realiza la depuración. Cuando necesito usar IntelliSense para encontrar un control, solo escribo __ y aparece una lista de controles. Esto continúa con la convención de nomenclatura de prefijar un guión bajo a variables de nivel de módulo, como en int _id; .
Puede usar el sitio web oficial de Microsoft para las convenciones de nomenclatura de control de Visual Basic 6, y quizás combinarlo con las convenciones de nomenclatura de C # recomendadas. Es muy específico, es muy utilizado por los desarrolladores en C # y también para los nombres de control, y aún se puede usar en un contexto de WPF o Windows Forms.
Convenciones de nomenclatura de control de Visual Basic 6: Convenciones de nomenclatura de objetos
C # recomendó convenciones de nomenclatura en general: convenciones generales de nomenclatura