programacion - notacion hungara para c#
¿Mejores prácticas para las convenciones de nomenclatura de la GUI de C#? (17)
Creo que existen convenciones de nomenclatura para facilitar el esfuerzo de codificación del desarrollador y ayuda en la capacidad de administración. Para mi entender, se debe seguir cualquier nombre que sea útil para acceder fácilmente.
Vi una cantidad de comentarios con un enfoque diferente, pero lo mejor que encontré en mis proyectos es el prefijo del primer nombre del control. Hay muchas razones detrás de seguir este enfoque.
- Intellisense juntaría todo el mismo tipo.
- Las ventanas de propiedad de formulario también mostrarían todo el mismo control ordenado
- En formularios complejos, puede identificar fácilmente que está tratando con etiquetas o cuadros de texto (por ejemplo, lblAccounts y txtAccounts)
- Un nuevo usuario puede lidiar fácilmente con la codificación.
- Imagine que tengo controles accountLst, accountlbl, accounttxt, accountgrd, accountChk en el mismo formulario.
Mientras se codifica, un desarrollador siempre sabe que está accediendo al cuadro de texto o a la etiqueta. Donde no está claro con qué nombre ha usado el otro desarrollador. Así que al escribir "lbl" intellisens traería toda la lista de etiquetas para elegir, donde si usabas el enfoque utilizado en el n. ° 5, intellisense traería todos los controles usando acc. Raramente vi hacer un ciclo con el nombre de control de inicio con "cuenta" más o menos. Esto significa que no ayudaría en ningún incidente raro.
Mi apuesta es hacer cosas que ayuden a entender el código fácilmente para otro desarrollador. Porque a medida que crezcas en tu compañía, no siempre harás codificación, alguna otra persona vendrá y tomará tu asiento.
¡La elección es tuya, de la manera que quieras!
Las GUI, ya estén escritas en WinForms o XAML, parecen tener las convenciones de nomenclatura más diferentes entre los proyectos que veo. Para un simple TextBox para el nombre de una persona, he visto varias convenciones de nombres:
TextBox tbName // Hungarian notation
TextBox txtName // Alternative Hungarian
TextBox NameTextBox // Not even camelCase
TextBox nameTextBox // Field after field with TextBox on the end
TextBox TextBoxName // Suggested in an answer...
TextBox textBoxName // Suggested in an answer...
TextBox uxName // Suggested in an answer...
TextBox name // Deceptive since you need name.Text to get the real value
TextBox textBox1 // Default name, as bad as you can get
Cumplo las reglas de StyleCop para todos mis archivos .cs normalmente y veo que otros también lo hacen, pero la GUI tiende a romper estas reglas o a variar enormemente. No he visto ninguna guía de Microsoft que se refiera específicamente a elementos de GUI en lugar de solo variables normales, o incluso ejemplos que se aplicarían fuera de una aplicación de consola.
¿Cuáles son las mejores prácticas para nombrar elementos en una GUI?
Esta locura húngara / VB6-naming necesita detenerse.
Si Microsoft realmente quería que nombrara sus controles según su tipo, ¿por qué Visual Studio no pega automáticamente el ''txt'' o ''btn'' cuando agrega el control a su formulario web / win?
Este no es mi invento, pero me gusta:
TextBox uxName = new TextBox();
Label uxNameLabel = new Label();
Button uxAccept = new Button();
Prefiero esto a la notación húngara ya que todos los controles de mi UI aparecen en un bloque en intelisense. UX para "experiencia de usuario". También es bueno si cambia un control de un cuadro de texto a un cuadro combinado o algo así, ya que el nombre no cambiará.
He estado trabajando con un equipo últimamente que se está moviendo de MFC (6.0 ...). Allí tendrían algo así como
CString Name;
CEdit ctlName;
La forma más fácil de migrar ha sido usar algo como
TextBox ctlName
Es suficiente recordatorio de que la variable es el control y no el valor del control.
Creo que incluir el tipo como parte del nombre es VIEJO.
- editar - Otra ventaja es que todos los controles se agrupan al navegar. Si se utilizara el tipo real, los controles ComboBox estarían bastante lejos de los controles TextBox.
La misma convención que todo lo demás en .NET: nombre descriptivo de la caja de camello, seguido opcionalmente por un sufijo si necesita distinguir diferentes clases para la misma "cosa" lógica. Por ejemplo:
string name; // a name
TextBox nameText; // the control used to edit the name
Label nameLabel; // the control used to label the edit control
List<string> nameList; // a list of names
y así sucesivamente hasta el infinito. Realmente no importa cuáles son los sufijos, siempre que sean coherentes y descriptivos.
Lo más importante acerca de las convenciones de nomenclatura es elegir algo que tenga sentido, obtener un consenso de todas las partes y mantenerlo como si tu vida dependiera de ello.
En cuanto a qué convención usar, votaría por esta:
TextBox name
Es corto y tiene un valor semántico como identificador. En cuanto al tipo de identificador, confío en Visual Studio para decírtelo, ya que tiende a ser bueno en ese tipo de cosas.
Mi propia práctica es: Escriba _contextDescriptionType. P.ej:
TextBox _searchValueTextBox
De todos modos, nombrar una convención es demasiado personal o está impuesta por reglas generales. En cualquier caso, debe documentarse en alguna parte para que todos los desarrolladores de proyectos puedan acceder fácilmente.
Nombro todos los elementos de la interfaz de usuario TypeDescriptor. Siguiendo su ejemplo, TextBoxName .
Ojalá alguien se convirtiera en la autoridad en este tema y simplemente lo dijera como es, y empiece a aplicarlo ... Lo peor para mí es cuando las personas lo mezclan en la misma aplicación o, peor aún, en la misma clase.
He visto algunas cosas bastante horribles con txtName, NameTextBox, name y textBox1, todas usadas en la misma forma ... yuck.
Donde trabajo tenemos un documento de estándares que nos dice cómo hacerlo, dónde hacerlo, y creo que solo el 20% de las personas incluso se preocupa por probar y conformarse.
Normalmente cambiaré algo si Fxcop me grita.
http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29
Tenga en cuenta que: Microsoft .NET recomienda UpperCamelCase (también conocido como "Pascal Style") para la mayoría de los identificadores. (se recomienda lowerCamelCase para los parámetros).
Para los elementos que no planeo usar en mi código, simplemente dejo que el diseñador lo maneje por mí; si se convierten en algo usado en mi código, se cambian a algo significativo y que resulta ser descriptionType (nameTextBox). Es la forma en que el diseñador los crea si se les proporciona suficiente información (consulte los elementos del menú - "Salir" se convierte en exitMenuItem).
Si hay una buena separación de preocupaciones en el diseño de una aplicación, supongo que no habrá necesidad de nombrar botones como LoginButton, LoginBtn o btnLogin. Si el propietario del objeto es un elemento de IU, entonces llamemos "Iniciar sesión" y, si el propietario no es un elemento de IU, el objeto está en un lugar equivocado.
Tiendo a usar c_typeName (tenga en cuenta que el tipo y el nombre son diferentes), por ejemplo, c_tbUserEmail para un cuadro de texto en el que el usuario debe escribir su correo electrónico. Lo encuentro útil porque cuando hay muchos controles, puede ser difícil encontrarlos en la lista intellisense de millas, así que al agregar el prefijo c_ puedo ver fácilmente todos los controles en esa forma.
Uso el húngaro de la vieja escuela ... txt para TextBox, btn para Button, seguido de una palabra generalizada, luego una palabra más específica. es decir:
btnUserEmail
Mucha gente ha dicho cosas como "¡Oh, eso es tan viejo, llamadas VB6!" Pero en una aplicación UI Rich winforms, puedo encontrar y modificar cosas más rápido porque, generalmente, lo primero que sabes sobre un control es su tipo, luego su categoría y luego ser específico. Mientras que los chicos de la convención de nombres de estilo más nuevos están atascados tratando de recordar lo que llamaron ese cuadro de texto.
Uso la notación Hungation con una pequeña diferencia.
Ahora trabajo en un proyecto que tiene una interfaz de usuario bastante rica. Así que encontrar, con Intellisense, un botón llamado, digamos, btnGetUsers es muy fácil.
Las cosas se complican cuando la aplicación puede obtener usuarios de diferentes ubicaciones. Eso es diferentes controles. Así que empecé a nombrar mis controles después de dónde se encuentran y todavía uso la notación húngara.
Como ejemplo: tabSchedAddSchedTxbAdress significa que txbAddress es un cuadro de texto donde se puede insertar una dirección y se encuentra en la pestaña Agregar programación desde el Control de pestaña de programación. De esta forma puedo encontrar controles muy fáciles y, cuando escribo simplemente "btn", no obtengo, de inmediato, muchos botones de toda la interfaz de usuario.
Por supuesto, esto es solo para ayudarme a mí mismo. No estoy al tanto de tales mejores prácticas. Sin embargo, ayuda mucho.
Mosu ''
Uso la notación húngara, que hace que sea fácil encontrar controles en páginas grandes.
Usted tiene las Pautas para Nombres de Microsoft. No veo todo, pero es un buen punto de partida
Yo suelo:
TextBox nameTextBox;
Al igual que yo usaría:
MailAddress homeAddress;
La razón de esto es que en estos casos "TextBox" y "Dirección" son descriptivos de lo que representa el objeto, no cómo se almacena o se usa. Pero en otro caso, como almacenar el nombre completo de una persona, usaría:
string fullName;
No:
string fullNameString;
Porque "Cadena" no es descriptivo de lo que representa el objeto, sino solo cómo se almacena.