¿Los prefijos de tipo y alcance merecen convenciones de nomenclatura?

Recientemente comencé mi primer trabajo como desarrollador de software, me sorprendió que me dijeran que no tenía que seguir ninguna convención de nomenclatura en mi código. El código escrito por grupos que trabajaban en otros proyectos más grandes seguía las convenciones de nomenclatura, pero como me llevaron a escribir una nueva aplicación independiente, la sensación fue que no importaba especialmente. Era la última de mis preocupaciones, así que simplemente tomé esa convención existente y corrí con ella.

int nTickCount  
bool bConnected  
object[] m_aItems  
fSum += fWeight * fValue  
class cManager  
enum etSystemStates  
etSystemStates eState   
cManager.cs

¿Pero realmente vale la pena? Me resulta difícil juzgar el efecto neto que tiene este tipo de convención de nomenclatura en la comprensión y detección de errores, pero, visualmente , se ve un poco feo. Además, tener cada clase y archivo en el proyecto llamado cSomething parece bastante estúpido.

No tengo la ilusión de que sea un gran problema en comparación con las cosas que marcan una diferencia obvia, como los algoritmos y las arquitecturas que emplea. Pero cualquier convención que afecte a cada línea de código que escribo parece ser correcta.

¿Cuál encuentra la convención de nomenclatura más elegante y efectiva, si es necesario utilizar alguna? ¿Denota tipo y / o alcance?

Joel Spolsky escribió un artículo sobre por qué existe la notación húngara y para qué está destinada, que puede ayudar a responder su pregunta.

Los prefijos como tbl para una tabla de base de datos, int para un número entero, etc., generalmente no son útiles; en esos casos, es trivial averiguar qué es qué es el contexto o las herramientas de desarrollo. Algo así como el diablillo para las medidas imperiales y las medidas métricas tiene mucho más sentido porque de lo contrario solo se puede ver que son números de coma flotante.

area = width * height

se ve perfectamente bien mientras

impArea = metWidth * impHeight

te muestra directamente que algo está mal.

Personalmente solo uso nombres descriptivos de variables. $ 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 lenguaje como de tipo semántico.

Lo que estás describiendo se llama notación húngara . Alguna 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 su equipo está utilizando las mismas convenciones, se vuelven mucho más útiles. Usarlos por su cuenta es menos útil.

En idiomas fuertemente tipados estáticamente, no solo copie el tipo de una variable. Por ejemplo, "bSubscriptions" es un mal nombre para una variable booleana en C # o Java, porque su IDE ya sabe de qué tipo es. En C, por otro lado, que carece de un tipo booleano, esta sería información útil.

En C # y Java, puede considerar un prefijo para mostrar que un objeto puede ser nulo. O que se ha escapado una cadena html. O que representa una expresión regular, o una declaración sql. O que se ha ordenado una matriz. Use su imaginación.

Básicamente se trata de preguntarse qué le gustaría que le dijera un nombre de variable, y eso depende mucho del dominio y el idioma en el que esté trabajando.

Existen algunos "estilos" diferentes de convención de nomenclatura, y la mayoría de ellos tienen cierto 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 "sum", "weight" y "value", es posible que desee dar nombres más significativos: "totalCost", "lumberWeight", "lumberValuePerOunce" (estoy haciendo algunas suposiciones aquí)

Encuentro convenciones como anteponer nombres de variables con un carácter que significa 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 ( http://msdn.microsoft.com/en-us/library/ms229042.aspx ), que es bastante similar a la de Java (la principal diferencia es que Microsoft favorece Pascal Case para los nombres de los miembros, mientras que Java favorece el caso del camello).

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

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

Prefijar 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.

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

En cuanto al segundo punto, ¿qué sucede cuando, por ejemplo, una selección prematura de int se reemplaza por larga o doble? Peor aún, ¿qué sucede cuando una clase concreta se refactoriza en una interfaz con múltiples clases de implementación? Cualquier práctica que aumente la carga de los escenarios de mantenimiento realistas me parece cuestionable.

También puede depender de por qué está prefijando el nombre, en lugar de solo con qué prefijo.

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

Tener un prefijo de bt para los botones hace que sea más 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 generalmente no es tan útil de todos modos), ni para el significado, contexto o unidad (que es la idea original detrás de la notación húngara).

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

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

Los prefijos a menudo tienen sentido para los objetos, por ejemplo, en un formulario en el que puede tener 20 cuadros de texto que los llaman todos tienen tbSomethingsentido.

Sin embargo, sobre todo no creo que valga la pena, especialmente para los tipos de valor.

Por ejemplo, suponga que tiene:

short shortValue = 0;
//stuff happens

Meses después descubre que necesita cambiarlo: un corto no es lo suficientemente grande. Ahora tu tienes:

int shortValue = 0;
//stuff happens

A menos que ahora también cambie el nombre de la variable (más riesgo de romper el código que cambiar el tipo en este caso), ahora tiene un código confuso.

Es mejor tener un nombre que describa lo que contiene:

int loopCounter = 0;
//stuff happens

Si más tarde eso necesita cambiar a largo: no hay problema.

Quizás haya más argumentos para estas convenciones en lenguajes de tipo dinámico o aquellos sin IDE.

Siempre he sido propenso a usar una abreviatura de 2 a 4 caracteres para el tipo frente a la variable en sí. A veces parece tedioso, pero cuando trabajas con tipos o situaciones de datos complejos, se vuelve beneficioso. Creo que cae en la categoría inferior de camello.

Mirando su ejemplo anterior, sería ligeramente modificado para ser:

int intTickCount;
bool boolConnected;
object[] aobjItems;

Las matrices siempre tienen una a delante del tipo para designar la matriz. Esto también me permite agrupar instancias de variables similares. Por ejemplo, puedo usar ...

taStore.Fill(dtStore);

... que indica que mi Store TableAdapter se está llenando en Store DataTable.

Siempre he tratado de adherirme al principio básico de que los prefijos y / o sufijos deben insertarse solo cuando hace que el código sea más legible (como en inglés simple).

Cuanto menos críptico, mejor ...

¿Por qué tener un método como este?

public boolean connect( String h, int p );

Cuando puedes tener algo como esto:

public boolean connect( String hostName, int port );

Además, los IDE de hoy en día realmente tienen una herramienta poderosa para refactorizar (especialmente Java) variables, nombres de métodos, clases, etc. La idea de decir que la información máxima con la menor cantidad de caracteres está pasada de moda.