¿Mejores prácticas para las convenciones de nomenclatura GUI de C#? [cerrado]

Utilizo:

TextBox nameTextBox;

Justo como yo usaría:

MailAddress homeAddress;

La razón de esto es que en estos casos "TextBox" y "Address" es descriptivo de lo que representa el objeto, no de cómo se almacena o utiliza. Pero en otro caso, como almacenar el nombre completo de una persona, usaría:

string fullName;

No:

string fullNameString;

Porque "String" no es descriptivo de lo que representa el objeto, sino solo de cómo se almacena.

La misma convención que todo lo demás en.NET: camel case descriptive name only, opcionalmente seguido de 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 sean los sufijos, siempre y cuando sean consistentes y descriptivos.

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 mis controles de interfaz de usuario se muestran en un bloque en intelisense. UX para "Experiencia de usuario". También es bueno si cambias un control de un cuadro de texto a un combobox o algo así, ya que el nombre no cambiará.

Lo más importante de las convenciones de nombres es elegir algo que tenga sentido, obtener un consenso de todas las partes y atenerse a él como si su 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 del identificador, confiaría en Visual Studio para decirles que, ya que tiende a ser bueno en ese tipo de cosas.

Desearía que alguien se convirtiera en la autoridad en este tema y simplemente lo dijera como es, y comenzara a aplicarlo... Lo peor para mí es cuando la gente lo mezcla 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 todos usados en el mismo formulario... qué asco.

Donde trabajo tenemos un documento de estándares que nos dice cómo hacerlo, dónde hacerlo, y creo que solo el 20% de la gente se preocupa por intentarlo y conforme.

Normalmente cambiaré algo si Fxcop me grita.

Http://en.wikipedia.org/wiki/Naming_conventions_%28programming%29

Estilos de mayúsculas

Tenga en cuenta que: Microsoft. NET recomienda UpperCamelCase (también conocido como "Estilo Pascal") para la mayoría de los identificadores. (Se recomienda una cámara baja para los parámetros).

Utilizo la notación de Hungación 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 es capaz de obtener usuarios de diferentes ubicaciones. Eso son diferentes controles. Así que empecé a nombrar mis controles después de donde se encuentran y todavía utilizar 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 la pestaña Programación. De esta manera puedo encontrar controles muy fáciles y, cuando escribo simplemente "btn" no recibo, a la vez, muchos botones de toda la interfaz de usuario.

Por supuesto, esto es solo para ayudarme a mí mismo. No soy consciente de una buena práctica. Sin embargo, ayuda mucho.

Mosu '

Nombro todos mis elementos de interfaz de usuario TypeDescriptor. Siguiendo su ejemplo, TextBoxName.

He estado trabajando con un equipo últimamente que se está moviendo desde MFC (6.0 ...). Allí tendrían algo como

CString Name;
CEdit ctlName;

La forma más fácil de migrar ha sido usar algo como

TextBox ctlName

Basta con recordar que la variable es el control y no el valor del control.

Creo que incluir el tipo como parte del nombre es simplemente ANTIGUO.

Edit editar -- Otro beneficio es que todos los controles se agrupan al navegar. Si el tipo real fueron utilizados, los controles ComboBox sería bastante lejos de los controles del cuadro de texto.

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 a, puede ser difícil encontrarlos en la lista de millas de intellisense, por lo que al agregar el prefijo c_ puedo ver fácilmente todos los controles en esa forma.

Esta locura de nombrar húngaro/VB6 tiene que parar.

Si Microsoft realmente quería que nombraras tus controles en función de su tipo, ¿por qué Visual Studio no selecciona automáticamente 'txt' o 'btn' cuando añades el control a tu formulario web/win?

Uso la notación húngara, que hace fácil encontrar controles en páginas grandes.

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 eso pasa a ser descriptionType (nameTextBox). Es cómo el diseñador los crea si se le da suficiente información (echa un vistazo a los elementos del menú Exit "Exit" se convierte en exitMenuItem).

Mi propia práctica es: Type _contextDescriptionType. Por ejemplo:

TextBox _searchValueTextBox

De todos modos la convención de nomenclatura es demasiado personal o impuesta por reglas generales. En cualquier caso, debe documentarse en algún lugar para que todos los desarrolladores de proyectos puedan acceder fácilmente.

Tiene las Pautas para Nombres de Microsoft. No sigo todo, pero es un buen punto de partida

Creo que la convención de nombres existe para facilitar el esfuerzo de codificación del desarrollador y ayuda en la capacidad de administración. A mi entender cualquier nombre que es útil en fácil acceso debe ser seguido.

Vi el número de comentarios con un enfoque diferente, pero lo mejor que encontré en mis proyectos es prefijar el nombre de control 1st three. Hay muchas razones detrás de seguir este enfoque.

1. Intellisense reuniría a todo el mismo tipo.
2. Las ventanas de propiedades de formulario también mostrarían todas las mismas control ordenado
3. En formularios complejos puede identificar fácilmente que está tratando con etiqueta o cuadro de texto (por ejemplo. lblAccounts y txtAccounts)
4. Un nuevo usuario puede lidiar fácilmente con la codificación.
5. Imagine que tengo controles accountLst, accountlbl, accounttxt, accountgrd, accountChk en el mismo formulario.

Mientras codifica, un desarrollador siempre sabe que está accediendo a un cuadro de texto o etiqueta. Donde como él no está claro con qué nombre el otro desarrollador ha utilizado. Así que con solo escribir" lbl " intellisens traería toda la lista de etiquetas para elegir, donde está si ha utilizado el enfoque utilizado en #5, entonces intellisense traería todos los controles utilizando acc. Rara vez vi hacer algún bucle con el nombre de control comenzar con "cuenta" o algo así. 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 otros desarrolladores. Porque a medida que creces en tu carrier, no siempre haces codificación, alguna otra persona vendría y tomaría tu asiento.

¡La elección es tuya, de la manera que quieras!

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 interfaz de usuario, llamémoslo Login y si el propietario no es un elemento de interfaz de usuario, entonces el objeto está en un lugar equivocado.