En los últimos años he estado usando la convención de nomenclatura de FirstNameTxt cuando me refiero a un Control de cuadro de texto para un campo 'Nombre'. Sin embargo, he notado que la mayoría de los otros desarrolladores tienden a utilizar la convención de nomenclatura txtFirstNametxtFirstName vs FirstNameTxt
¿Cuál es la mejor convención para usar? y ¿por qué es preferible al otro método?
Desde Visual Studio 2010, no hay absolutamente ninguna razón para utilizar la notación húngara.
La única razón que uno podría imaginar: para buscar fácilmente controles similares con intellisense, se va con el nuevo intellisense que busca en texto completo.
Así escribir Text en el editor de código que se encuentra todo: firstNameText, lastNameText, anyText.
Y es mucho más fácil leer "firstNameText" que "txtFirstName" en el código.
Verdaderamente no veo cómo agregar texto al final de la palabra es menos notación húngara que agregarlo al principio de la palabra. –
@Sergej: se debe a que el texto (o más bien TextBox) al final no tiene nada que ver con el tipo de propiedad; es un nombre legible por humanos de una cosa: primer nombre cuadro de texto. –
@MarkJ: ¿realmente leíste mi respuesta? –
Me gusta usar la notación húngara, antepuesto a una abreviatura de 3 letras, si por cualquier otra razón, todos los controles de la caja de texto se agrupan en la lista de controles de la página.
+1 Exactamente por qué lo hago –
+1 por mi por la misma razón, aunque a veces me siento un poco inconsistente ya que los controles son la * única * cosa con la que uso la notación húngara. –
+1 - Nuestro estándar dentro de nuestro grupo de desarrollo es el caso húngaro para todos los controles para agruparlos (con un documento que indique la abreviatura por control) –
Uno no es mejor que el otro. Lo más importante es ser coherente en cualquier convención que elija.
Como ha estado usando su convención actual durante los últimos años, no cambiaría porque entonces tendrá una convención quebrada. A menos, por supuesto, que elija retroceder y refactorizar todo su código existente para la nueva convención. Pero eso plantea la pregunta "¿por qué molestarse?".
No estoy de acuerdo. Uno proporciona un beneficio (agrupando controles del mismo tipo en Intellisense), el otro no le proporciona nada. La convención no es una justificación absoluta para sí misma. –
@Adam: No estoy de acuerdo contigo. El otro le proporciona una mejor lectura, el primero no le proporciona nada con el nuevo intellisense. –
El "otro" (el segundo) no proporciona nada. No es necesario asociar el tipo al nombre para identificar el tipo de la variable. ¿Por qué dices que el primer enfoque no proporciona nada con el nuevo intellisense? –
A partir de la investigación que hice sobre el mismo tema parece que no hay un consenso verdadero o una mejor práctica. La gente argumentará que debería ser txtFirstName, FirstName y FirstNameTxt. Mi sugerencia es que siempre que sea consistente, entonces estás bien. Nada es peor que codificar cuando cambian los nombres.
Como un lado utilizo txtFirstName.
+1. Tanto 'txtFirstName' como' FirstName' (aunque yo diría 'firstName', ya que es una variable de instancia, no un miembro público) tiene sentido, pero' FirstNameTxt' no me da ninguno; la información de tipo ya está disponible, ¿por qué ponerlo en el nombre si no va a ayudar en la clasificación? –
@ Adam: Es porque es un "Cuadro de texto del primer nombre", no el "Nombre" en sí. Podría tener otra propiedad llamada 'FirstName' de tipo cadena que haría exactamente lo que se nombra. –
@ František: No debe llamarse 'FirstName' en absoluto, ya que las variables de instancia (si estamos hablando de las convenciones recomendadas por MS) deben ser camel-cased, no pascal-cased. –
Las directrices de .NET Framework recomiendan que el primer carácter esté en minúsculas. Al igual que "txtFirstName" o "awesomeVariable", etc.
http://msdn.microsoft.com/en-us/library/x2dbyw72(v=VS.71).aspx
Consulte esta lista de recomendaciones. :)
Generalmente uso "ux" para "User eXperience" como prefijo para los nombres de control. Esto hace que sea más fácil cambiar los tipos de control manteniendo el mismo nombre. Como los controles tienen una jerarquía de herencia compartida, a menudo es posible cambiar de uno a otro, por ejemplo de una etiqueta a un cuadro de texto sin cambiar el prefijo de "lbl" a "txt". También agrupa todos los controles en la lista para que no tenga que recordar el tipo de control que estoy buscando.
Uso "ForenameTextbox" para los controles, porque odio la notación húngara el ruido que agrega, pero "ux" es uno nuevo - me gusta eso –
¿Nunca tiene dos controles de diferentes tipos que muestren la misma información? Por ejemplo, dependiendo de la seguridad del usuario, ¿muestra un cuadro de texto FirstName o una etiqueta FirstName? –
No a menudo en la misma forma/control. Casi siempre hago formularios separados o controles de usuario para vistas de solo lectura/editables. Cuando sucede, normalmente agrego un sufijo, es decir uxFirstNameLabel. –
No uso la notación húngara. Si tengo problemas para recordar los nombres exactos de los controles en mi formulario, entonces estoy haciendo algo mal. Lo más probable es que la clase de formulario esté haciendo demasiado y tiene varias responsabilidades.
Para arreglarlo, generalmente dividir el formulario en subsecciones usando controles de usuario y separar cuidadosamente las preocupaciones entre ellos. Como una ventaja adicional, el código es más fácil de probar.
+1 Buena pregunta.¿Podría la persona que votó cerrar esta pregunta por favor dejar un comentario explicando el motivo? – MarkJ
evidentemente, sintieron que era subjetivo y argumentativo, que de alguna manera lo es. – Malfist