WPF UI elemento convenciones de nomenclatura

Question

Aunque Hungarian notation se considera una mala práctica hoy en día, todavía es bastante común para codificar el tipo en el nombre de elementos de la interfaz, ya sea mediante el uso de 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 compañeros de trabajo (o por usted mismo hace mucho tiempo) sea más fácil de leer (en mi experiencia). El argumento generalmente planteado en contra de hacer esto - usted tiene que cambiar el nombre de la variable si el tipo cambia - no es muy fuerte, ya que cambiar el tipo de elemento de UI generalmente requiere reescribir todas las partes del código si se hace referencia de todos modos .

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 me haya perdido? Esta es su oportunidad de decir "No hagas esto, porque ...".

EDIT: Sé que con databinding la necesidad de nombrar elementos de IU disminuye. Sin embargo, es necesario algunas veces, p. al desarrollar controles personalizados ...

Answer 1

Personalmente, me parece que WPF cambia las reglas cuando se trata de esto. A menudo, puede salirse con la suya con poco o ningún código, así 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 nombre en el código. Con una interfaz de usuario grande, la notación semi-hú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 código de control, a menudo es mejor utilizar propiedades o comportamientos adjuntos para hacerlo, en cuyo caso nunca se trata de más de un control. Si está trabajando en UserControl o Window code-behind, solo usaría "Title" y "Name" en lugar de "txtTitle", especialmente porque ahora probablemente solo tratará con unos pocos controles limitados. 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 real x: Elementos de nombre para sus UI ...

Answer 2

Me gusta usar una convención (solo una buena idea en general), pero para las cosas de UI me gusta tener el tipo de control en la parte delantera, seguido del nombre descriptivo - LabelSummary, TextSummary, CheckboxIsValid, etc.

Suena de poca importancia, 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.

Answer 3

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 mal. 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 IU en WPF se debe a otros elementos en el mismo XAML.

Y personalmente, encuentro "lblTitle, lblCompany, txtFirstName" más difícil de leer que "Título". No tengo .intWidth y .intHeight (¡adiós lpzstrName!). ¿Por qué tiene .lblFirstName? Puedo entender TitleField o TitleInput o lo que sea mucho más, ya que es descriptivo del qué, no del cómo.

Para mí, querer tener ese tipo de separación normalmente significa que mi código de interfaz de usuario está tratando de hacer demasiado; por supuesto, se trata de un elemento de IU, ¡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 estaría codificando aquí?

Answer 4

En WPF prácticamente nunca necesita (ni desea) nombrar sus controles. Por lo tanto, si está utilizando las mejores prácticas de WPF, no importará lo que llamaría nombre sus controles si tiene una razón para nombrarlos.

En las raras ocasiones en las que realmente desea dar un nombre a un control (por ejemplo, para un ElementName = o TargetName = referencia), prefiero elegir un nombre que describa el propósito del nombre, por ejemplo:

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

<DataTrigger> 
    ... 
    <Setter TargetName="hilightArea" ... 

Answer 5

Incluso desde la perspectiva de Winforms no me gusta semi-húngaro.

La mayor desventaja en mi opinión, y he escrito MUCHO código en la interfaz de usuario es que el húngaro hace que los errores sean más difíciles de detectar. El compilador general recogerlo si se intenta cambiar la propiedad comprobado en un cuadro de texto, pero no va a recoger algo como:

lblSomeThing.Visible = someControlsVisible; 
txtWhatThing.Visible = someControlsVisible; 
pbSomeThing.Visible = someControlsVisible; 

Me resulta 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 con todos los controles que se relacionan con un concepto lógico particular (como el título o agregar comentarios). Casi nunca quiero encontrar solo uno o todos los cuadros de texto que estén en este control.

Es posiblemente irrelevante en WPF, pero creo que debe evitarse el húngaro en todo momento.

Answer 6

Estoy de acuerdo con las otras respuestas en que son principalmente preferencias personales, y lo más importante es solo ser coherente.

Sobre la necesidad de nombrar en absoluto, dada la prevalencia del enlace de datos ... una cosa que quizás desee considerar es si su UI alguna vez se somete a pruebas automatizadas. Algo como QTP encuentra los elementos visuales en una aplicación por Nombre, por lo que un ingeniero de automatización que escriba scripts de prueba apreciará mucho cuando cosas como pestañas, botones, etc. (cualquier control interactivo) estén bien nombrados.

Answer 7

Prefijo cualquier nombre de interfaz de usuario con dos guiones bajos, como en __, por lo que se ordena antes que otras propiedades cuando se depura. Cuando necesito usar IntelliSense para encontrar un control, simplemente escribo __ y aparece una lista de controles. Esto continúa la convención de denominación de prefijar un solo subrayado a variables de nivel de módulo, como en int _id;.

Answer 8

Puede utilizar 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 recomendadas de C#. Es muy específico, es ampliamente utilizado por los desarrolladores en C# así como para los nombres de control, y aún se puede usar en un contexto WPF o Windows Forms.

Visual Basic 6 control de las convenciones de nomenclatura: Object Naming Conventions

C# recomienda convenciones de nomenclatura en general: General Naming Conventions