Convenciones de nomenclatura de elementos de interfaz de usuario de WPF

En mi experiencia - En WPF cuando cambias el tipo de un control, normalmente no tienes que reescribir ningún código a menos que hayas 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 UI en WPF son por otros elementos en el mismo XAML.

Y personalmente, encuentro "lblTitle, lblCompany, txtFirstName" más difícil de leer que "Title". No tengo .intWidth y .En la noche (adiós ¡ipzstrName!). Por qué lo has hecho .¿Primer nombre? Puedo entender TitleField o TitleInput o lo que sea mucho más, ya que es descriptivo del qué, no del cómo.

Para mí, desear 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 interfaz de usuario, está en el código de la ventana! Si no estoy tratando con código alrededor de un elemento de interfaz de usuario, ¿por qué en el mundo lo estaría codificando aquí?

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

Suena menor, pero la razón principal para poner el tipo primero es que aparecerán juntos en la lista Intellisense all todas las etiquetas juntas, casillas de verificación, y así sucesivamente.

Incluso desde una perspectiva Winforms no me gusta 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 intenta cambiar la propiedad marcada en un cuadro de texto, pero no captará algo como:

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

Me resulta mucho más fácil 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 a btnAddComments con una ventana 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 en particular (como título, o agregar comentarios). Casi nunca quiero encontrar cualquiera o todos los cuadros de texto que pasan a estar en este control.

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

De acuerdo con las otras respuestas que es principalmente preferencia personal, y lo más importante es solo para ser consistente.

Sobre la necesidad de nombrar en absoluto, dada la prevalencia de la unión de datos... una cosa que podría considerar es si su interfaz de usuario alguna vez está sujeta 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 escribe scripts de prueba apreciará mucho cuando cosas como pestañas, botones, etc. (cualquier control interactivo) están todos bien nombrados.

En WPF prácticamente nunca necesitas (o incluso quieres) nombrar tus controles. Por lo tanto, si está utilizando las mejores prácticas de WPF, no importará cómo llamaría a sus controles si tuviera una razón para nombrarlos.

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

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

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

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

Puede utilizar el sitio web oficial de Microsoft para las convenciones de nomenclatura de control de Visual Basic 6, y tal vez 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 todavía se puede utilizar en un contexto WPF o Windows Forms.

Visual Basic 6 control naming conventions: Object Naming Conventions

C# convenciones de nomenclatura recomendadas en general: Convenciones de nomenclatura generales