Luchando por no usar la notación húngara

He visto argumentos a favor y en contra de Systems Hungarian . Durante algunos años he estado trabajando en un proyecto heredado que utiliza este sistema al nombrar cada variable, función con un prefijo del tipo de variable, por ejemplo (strName, intAge, btnSubmit, etc.) (conozco los prefijos originales de las aplicaciones húngaras por el tipo de variable, no el tipo). Me gustaría que mi próximo proyecto lo abandone por completo, pero me resulta más difícil nombrar cosas similares de forma única sin recurrir a él.

Digamos que tengo un formulario web para recopilar direcciones de correo electrónico y almacenarlas en una tabla de base de datos, y un botón que llama a la función que guarda la dirección en la base de datos.

Si estoy usando la notación de estilo húngaro, podría llamar al cuadro txtEmailel botón btnEmaily el valor contenido en el cuadro de texto strEmail. Entonces podría usar una función storeEmail(strEmail)para almacenar el correo electrónico. Tengo una convención clara aquí, es obvio cuál es cada variable.

¿Cuál sería la mejor práctica para nombrar estas variables?

• sin recurrir a los sistemas húngaros,
• sin hacerlos demasiado largos o confusos
• y con una convención clara para usar en todo mi proyecto?

Su último punto es el más importante: haga lo que haga, debe ser coherente en su proyecto y con sus colegas. Hay dos formas principales de lograr la consistencia y, si es posible, debe usar ambas. En primer lugar, use una herramienta para verificar las convenciones de nomenclatura en tiempo de compilación. En el mundo .Net, StyleCop sería un buen ejemplo de dicha herramienta. La segunda forma de obtener coherencia es tener revisiones por pares de todo el código, para que todos puedan estar atentos.

Sus otros dos puntos parecen estar preguntando acerca de una alternativa. No estoy seguro de que necesites una alternativa; El punto sobre que el húngaro ya no es popular es que solía ser utilizado para describir el tipo cuando el sistema de tipos y las herramientas eran un poco, digamos, menos estrictos. Es decir, si estaba programando en C y pasando punteros, la única forma de realizar un seguimiento del tipo era utilizando el húngaro. Ahora, si está utilizando un lenguaje como C # o Java, no utilizará punteros (o muy raramente), por lo que la necesidad de cualquier tipo de húngaro desaparece. Además, los IDE modernos le permiten ver el tipo muy fácilmente al pasar el mouse sobre la variable o, en el peor de los casos, usar un atajo para ver la declaración original. Entonces, no creo que necesites ningún tipo de notación, solo nombra la variable por lo que hace. Si es una dirección de correo electrónico, simplemente use "correo electrónico" o "

Cuando se trata de formularios web / formularios de Windows / otras cosas gráficas, tiene sentido usar Systems Hungarian, ya que puede tener controles que están estrechamente unidos, por ejemplo, un cuadro de texto y una etiqueta que van juntos; podrías nombrarlos txtEmaily lblEmaildistinguirlos. En mi experiencia, esto es común y es realmente útil.

Pero en su código subyacente, este tipo de nombres es innecesario. Si tiene una variable de tipo stringque se está utilizando para almacenar un correo electrónico, simplemente asígnele un nombre email. Si, por alguna razón, se confunde, la mayoría de los IDE deberían permitirle pasar el mouse sobre él y ver su tipo. (Idealmente, en cosas OO, podría ser un atributo de algún objeto, y user.Emailes aún más claro).

Creo que si tiene más de un objeto declarado en su código que no es un control GUI que podría nombrarse correctamente email, algo está inherentemente mal con su diseño.

¿Qué hace que una variable sea "demasiado larga"?

En lugar de txtEmail, btnEmailusted podría utilizar UserEmailText, UserEmailButtony AdminEmailText,AdminEmailButton

El problema con esto es que puede comenzar a sentir que la variable comienza a alargarse:

AdminEmailIsValid comienza a limitar el tiempo que permitiría que la variable sea.

Además, puede comenzar a notar que está reutilizando un conjunto de variables y un conjunto de operaciones en esas variables. Para esto está diseñado OOP . En lugar de un conjunto de variables, cree un objeto genérico:

class EmailForm
  var textBox, button, text
  function storeEmail()

Luego puede crear una instancia de una nueva variable como clase y usar la misma notación de puntos para acceder a sus datos:

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

Por supuesto, esto está dirigido a lenguajes que usan el paradigma OOP, pero la mayoría de los lenguajes populares de desarrollo web están orientados a objetos o permiten código orientado a objetos (PHP, Python, C #, C ++, Java, JavaScript, ActionScript, etc. )