¿Los prefijos de tipo y alcance valen las convenciones de nomenclatura?

Joel Spolsky escribió un artículo acerca de por qué existe la notación húngara y para qué estaba destinado. pregunta.

Los prefijos como tbl para una tabla de base de datos, int para un entero, etc. generalmente no son útiles; es trivial averiguar qué es qué del contexto o de sus herramientas de desarrollo en esos casos. Algo como el imp para medidas imperiales y la métrica cumplida tienen mucho más sentido porque, de lo contrario, solo puedes ver que son números de punto flotante.

area = width * height

se ve perfectamente bien mientras

impArea = metWidth * impHeight

te muestra directamente que algo está mal.

Personalmente solo uso nombres de variables descriptivas. $ number_of_items es obviamente un recuento de enteros. $ input_file_handle, $ is_active y $ encrypted_password tienen tipos obvios tanto en términos de tipo de datos de idioma como de tipo semántico.

Lo que estás describiendo se llama notación húngara . Una vez se consideró la mejor práctica, pero generalmente está mal visto ahora.

El artículo de Wikipedia contiene una sección sobre sus pros y sus contras.

Sí, los prefijos pueden ser útiles, pero tengo un par de sugerencias:

Si todo tu equipo está utilizando las mismas convenciones, se vuelven mucho más útiles. Usarlos por tu cuenta es menos útil.

En los lenguajes con tipografía estática, no solo copie el tipo de variable. P.ej. "bSuscrito" es un mal nombre para una variable booleana en C # o Java, porque su IDE ya sabe de qué tipo es. Por otro lado, en C, que carece de un tipo booleano, sería información útil.

En C # y Java, puede considerar un prefijo para mostrar que un objeto puede ser nulo. O que una cadena ha sido html-escapada. O que representa una expresión regular, o una declaración SQL. O que una matriz ha sido ordenada. Usa tu imaginación.

Básicamente, se trata de preguntarte qué quieres que te diga un nombre de variable, y eso depende mucho del dominio y el idioma en el que estés trabajando.

Hay varios "estilos" diferentes de convención de nombres por ahí, y la mayoría de ellos tiene algún valor para hacer que el código sea comprensible.

Lo que es MUCHO más importante es: usar nombres descriptivos para variables y funciones. En su ejemplo con "suma", "peso" y "valor", es posible que desee dar nombres más significativos: "totalCost", "lumberWeight", "lumberValuePerOunce" (aquí hago algunas suposiciones)

Encuentro convenciones como anteponer nombres de variables con un carácter que indica que el tipo distrae bastante en la mayoría de los idiomas modernos.

La mayoría de los desarrolladores de .NET siguen las pautas de diseño de Microsoft ( enlace ), que es bastante similar a la de Java (la principal diferencia es que Microsoft favorece a Pascal Case para los nombres de los miembros) , mientras que Java favorece a Camel Case).

Aparte de eso, diría que la muestra de tu código es mucho menos legible debido al ruido adicional que has agregado.

Encuentro que, en su mayor parte, la guía de estilo de codificación de Google es bastante buena. Ya que le dijeron que puede usar cualquier estilo que desee, creo que debería comenzar por mirar esto, y elegir y elegir uno de ellos.

El prefijo de nombres de variables con tipos de datos (especialmente tipos de datos primitivos) aumenta el ruido visual, así como el riesgo de que un cambio pequeño se convierta en un cambio de nombre de gran explosión.

Re el primer punto, es "intStudentCount" realmente más claro que, por ejemplo, "numero de estudiantes"? ¿No sería "invoiceLineItems" al menos tan informativo como "aobjItems"? (El tipo de datos debe referirse al significado de los datos en el dominio del problema, no a la representación de bajo nivel).

En cuanto al segundo punto, ¿qué sucede cuando, por ejemplo, ¿Una selección prematura de int se sustituye por larga o doble? Lo que es peor, ¿qué sucede cuando una clase concreta se refacta en una interfaz con múltiples clases implementadoras? Cualquier práctica que incremente la carga de los escenarios de mantenimiento realistas me parece cuestionable.

También podría depender de por qué está prefijando el nombre, en lugar de con lo que prefieres.

Como ejemplo, tiendo a usar un prefijo de 1-2 letras para los nombres de los controles en un formulario. No es porque no sé que el compilador encontrará fácilmente la clase correcta para el botón (como ejemplo), pero tiendo a diseñar formas grandes primero y luego escribir la mayor parte del código.

Tener un prefijo de bt para los botones hace que sea fácil encontrar el botón correcto después, en lugar de tener muchos nombres mezclados.

Sin embargo, no uso prefijos para nombrar variables, ni para el tipo (que en general no es tan útil), ni para el significado, el contexto o la unidad (que es la idea original detrás de la notación húngara).

En mi opinión, depende del idioma y el tamaño del proyecto. En realidad, nunca he ido tan lejos como para usar los prefijos de tipo en todas mis variables, pero usted quiere nombrarlos de una manera clara.

En un lenguaje de tipo estático, como el que estás usando, cuanto más cómodo me siento con el sistema de tipos, menos importante es la notación húngara. Por lo tanto, en Java o C # y especialmente en Haskell ni siquiera pensaría en agregar esos prefijos, ya que sus herramientas pueden decirle el tipo de cualquier expresión dada y detectarán la mayoría de los errores resultantes de una mala interpretación de un tipo. div>