wpf - practices - textBoxEmployeeName vs employeeNameTextBox

namespace naming convention c#

Question

¿Qué convención de nomenclatura usas y por qué?

Me gusta usar employeeNameTextBox, porque:

• Parece más natural desde una perspectiva del idioma inglés.
• Me parece más fácil buscar con Intellisense.
• La convención es similar a la convención utilizada para eventos (MouseClickEvent, MouseClickEventHandler) y propiedades de dependencia (VisiblityProperty).

Nota: Estoy utilizando el nombre completo en lugar de una abreviatura (como "tb"), porque está en línea con las convenciones de nombres de MS que dicen que se debe evitar el uso de abreviaturas.

http://msdn.microsoft.com/en-us/library/ms229045.aspx

Answer 1

Supongo que es mejor seguir la Convención de Nombramiento de Objetos de Microsoft para nombrar tus controles tanto en C # como en Visual Basic.

Answer 2

Debería hacer lo que sea que haga que su código sea legible y autodocumentado. Seguir reglas duras y rápidas siempre es un error porque casi nunca cubren todos los aspectos de lo que se necesita hacer. No hay nada de malo en tener pautas (como no usar la notación húngara), pero es más importante que seas coherente y claro con tu convención de nombres, sea lo que sea, que sigas algunas reglas que se encuentran en Internet.

Answer 3

¿Por qué no EmployeeName? En serio, ¿cómo el tipo de control como parte del nombre cuando ya lo proporciona su IDE ayuda a proporcionar un código fácil de mantener? Considere las Reglas de Ottenger para el nombramiento de variables y clases

K

Answer 4

La única razón para usar primero el tipo de control en el nombre (textBoxEmployeeName) es para agrupar más fácilmente con Intellisense (todos los controles de la caja de texto aparecerían juntos). Más allá de eso, realmente no hay beneficio al usar esa manera. Encuentro que la segunda vía (employeeNameTextBox) es más fácil de leer y prefiero de esa manera personalmente, pero mucha gente todavía usará primero el tipo de control, ya que así fue como se hizo durante mucho tiempo.

Answer 5

No recomiendo la notación húngara en ninguna forma. textBoxEmployeeName es una forma de notación húngara. Así que apoyo el uso de employeeNameTextBox.

Personalmente, ni siquiera me molesto en usar la palabra TextBox, porque no es lo importante sobre la variable. Lo que es importante es "Empleado" y "Nombre". La adición de la palabra TextBox no solo te bloquea en un tipo determinado, sino que también dificulta mucho el cambio de ese tipo, ya que necesitas cambiar el nombre para normalizar tu código y hacerlo correcto. Supongamos por algún motivo que comenzó esto como un TextBox, pero posteriormente recibió el requerimiento de cambiarlo a DropDownList u otro tipo, ahora debe actualizar todo su código y JavaScript para que diga DropDownList en lugar de TextBox.

Es mucho más fácil olvidarse de intentar escribir sus nombres de variable, y simplemente nombrarlos. Usted tiene intellisense y compila errores de tiempo por una razón, ¿por qué no usarlo?

Answer 6

Yo (casi) siempre uso [controltype] [nombre descriptivo]. Quiero saber de inmediato con qué tipo de control estoy tratando cuando miro el código, y si NO recuerdo el nombre, intellisense puede ayudarme.

Solo el uso de un nombre descriptivo (EmplyeeName) no funciona para mí. ¿Qué tipo de control? ¿Es una etiqueta, un cuadro de texto o un cuadro combinado? O una cuerda? O un archivo? Es lo suficientemente importante como para que el tipo de control o variable sea siempre parte de ello.

Answer 7

A DEBE LEER son las Pautas XAML publicadas por Jaime:

Lea también más aquí

Answer 8

He usado tanto txtEmployeeName como employeeNameTextbox. Al igual que muchas de las publicaciones indicadas, esto es útil para agrupar. Un grupo por tipos de control (txtEmployeeName, txtManagerName) mientras que el otro puede agrupar diferentes controles relacionados juntos (employeeNameTextbox, employeePhoneTextbox, managerNameTextBox, managerPhoneTextbox). En muchos casos, encuentro que el último es más útil durante la codificación.

Answer 9

Me gustaría ir con [controlType] [DomainTerm] que en este caso es textBoxEmployeeName . La razón es que mientras se codifica el código C # detrás de usted se preocupan más por los controles de UI que por los términos específicos del dominio. La codificación lateral de UI (Ver) necesitamos identificar / reconocer el tipo de control más rápido, que es poco más importante que el dominio nombre específico en el lado Vista, y como leemos de '' Izquierda a derecha '', esta convención de nomenclatura es relevante. Generalmente uso txtEmployeeName o cmpEmployeeType, pero textBox en lugar de txt es preferido según las directrices de MS.

Answer 10

Mientras lo leí, un artículo vinculado en el artículo mencionado en la pregunta (a saber, Nombres de recursos ) utiliza el tipo de control al final, en FileMenu (y ArgumentException aunque no es un control).

Mi opinión personal es que esto también es más legible, ya que es el cuadro de texto del nombre del empleado y, por lo tanto, debe llamarse employeeNameTextBox , al igual que las palabras "File menu" se leen en ese orden. (Aunque sustituyo "Edit" por "TextBox" por brevedad, probablemente debería abandonar ese hábito para usar nombres de control consistentes con el nombre del entorno para ellos).

Answer 11

Nombrar tus variables es tan importante. Las convenciones de vista de clientes gruesos parecen tener el extremo corto del palo. Aquí están mis pensamientos:

1. Nunca pongas getters y setters para valores comerciales reales en tu vista. No hagas esto:

   public Name EmployeeName { get; set; }

2. Para obtener o establecer un EmployeeName, su código de estado debe llamar explícitamente a un método. Hágalo de esta manera porque proyecta que el estado no está almacenado en la vista, sino que puede derivarse o transponerse a la vista:

   public void SetEmployeeName(Name employeeName);
   public Name GetEmployeeName();

3. La notación húngara es estúpida. Era útil en los idiomas <= VB6 porque usaban el enlace tardío de los tipos de variables. Debes protegerte porque los desajustes de tipo son errores de tiempo de ejecución, no de compilación. Solo use txtEmployeeName si también usa strEmployeeName y intEmployeeNumber .

4. Si el prefijo del nombre de patrón no es coherente con su convención de nomenclatura, no lo haga para el tipo de control (que representa un patrón). Si no crearía un commandNameFormatting (en lugar de nameFormattingComamnd ), entonces no cree un textBoxEmployeeName .

5. Probablemente necesites un sufijo de algún tipo, ya que EmployeeName no describe suficientemente el propósito de la variable. El propósito de un cuadro de texto EmployeeName es recibir entrada. Podría llamarlo EmployeeNameTextBox si eso lo hace sentir cómodo, pero podría ser mejor llamarlo EmployeNameInput . Esto tiene la ventaja adicional de que si tiene una etiqueta, está claro que EmployeeNamePrompt (o EmployeeNameLabel ) no es lo mismo que el cuadro de texto. Sin algún tipo de sufijo descriptivo, no tienes una buena manera de diferenciar.

Answer 12

Ideas:

1. Evite codificaciones / abreviaciones.

2. El nombre debe destacarse de nombres similares en el mismo ámbito. Haga que la parte más exclusiva sea la parte más a la izquierda. Sospecho que tiene varios cuadros de texto, pero solo uno es el nombre del empleado.

3. Evite el contexto innecesario. ¿Están todos los nombres en esta página sobre empleados? ¿Es una página de "empleado"? Then EmployeeName es redundante. NameBox o NameControl deberían ser suficientes.

4. Evite el contexto innecesario: ¿tiene nombres que no son controles? Si es así, "Caja" o "Control" es útil; de lo contrario, no tanto.

Divulgación: soy el "ottinger" de "ottingers naming rules", que también evolucionó para ser el capítulo 2 de "Clean Code". Vea el formulario corto en http://agileinaflash.blogspot.com/2009/02/meaningful-names.html

Answer 13

Propongo una tercera opción: uiEmployeName. Razones:

1. No es húngaro Las dos anotaciones que mencionas son solo sabores de húngaro.
2. Si cambia el cuadro de texto de un nombre de empleado a un cuadro de lista, no necesita cambiar el nombre de sus variables.
3. Todo está bien agrupado en el intellisense sin involucrar el tipo de objeto.
4. El nombre del objeto sigue de cerca su función. Es un objeto orientado al usuario que obtiene el nombre del empleado.

Answer 14

Respuesta específica de WPF: Sin nombre en absoluto.

¿Por qué? Porque si estás desarrollando usando WPF no deberías nombrar tus controles. Si lo estás, estás haciendo algo mal.

WinForms requirió el nombre de los controles porque su enlace de datos era muy débil. WPF resuelve todo eso: el control en sí puede especificar sus datos y su comportamiento, por lo que no hay necesidad de nombrarlo.

Answer 15

Generalmente intento mantener el tipo de elemento corto, seguido de una etiqueta distintiva. Me parece que comunica rápidamente el tipo y el propósito del elemento:

txtEmployeeName;
lblEmployeeName;

Answer 16

En VB me gusta ir con [ControlName] _ [ControlType]. No recuerdo cómo comencé a hacer eso, pero supongo que es porque se siente como un orden lógico. También simplifica la codificación un poco porque las sugerencias de código se agrupan por la descripción del control en lugar del tipo de control.

Los controles de nombre de la misma manera en C #, excepto que sigo la preferencia de C # para camelCase: [controlName] _ [controlType].

También tiendo a usar mis propias abreviaturas para los tipos de control, aunque no son vagas.

Ejemplos:

VB: Save_Btn y NewFile_MItem (elemento del menú)

C #: save_btn y newFile_mItem

Funciona para mí, pero, por supuesto, todos los programadores tienen su estilo.