¿Prefiere nombres de variables con una abreviatura de los tipos de variables? (Notación húngara) [cerrado]

En mi trabajo actual, no hay pautas de codificación. Todo el mundo codifica como quiere. Lo cual está bien, ya que la empresa es pequeña.

Sin embargo, un chico nuevo recientemente propuso usar siempre la notación húngara. Hasta ahora, algunos de nosotros usamos algún tipo de notación húngara, otros no. Ya sabes, es una empresa de ingeniería, por lo que los estilos de codificación no importan mientras los algoritmos sean sólidos.

Personalmente, siento que estas abreviaturas de tipo pequeño son algo redundantes. Un nombre bien pensado generalmente entrega el mismo mensaje. (Además, la mayor parte de nuestro código tiene que ejecutarse en algunos DSP raros, donde un concepto como boolo floatno existe de todos modos).

Entonces, ¿cómo te sientes acerca de la notación húngara? Lo usas ¿Por qué?

Cuando la mayoría de la gente dice "notación húngara", en realidad están hablando de " sistemas húngaros ".

El sistema húngaro es completamente inútil y debe evitarse. No es necesario codificar el tipo de la variable en su nombre. Sin embargo, Systems Hungarian es en realidad un malentendido del húngaro original "real": Apps Hungarian.

En Apps Hungarian, no codifica el "tipo" en el nombre de la variable, codifica el "tipo" de la variable. Entonces no nWidth, pero pxWidtho emWidth(para "ancho en píxeles" o "ancho en ems" respectivamente). No strNamepero sNameo usName(para "nombre seguro" o "nombre inseguro" respectivamente - útil cuando se aceptan entradas de usuarios: cadenas inseguras).

Personalmente, normalmente tampoco me molesto. A menos que esté haciendo algo que convierta explícitamente el "tipo" de un valor (por ejemplo, he usado el prefijo "px" y "em" en el pasado porque comete errores como pxArea = emWidth * emHeightobvio).

Consulte también el artículo de Joel, " Hacer que el código incorrecto parezca incorrecto ".

pronombreUsted verboDebe adverbioNunca verboUse adjetivoNombre húngaroNotación, preposiciónIt verboHaces colectivoAnunciar todo AdverbioSo comparativoBloody adjectiveHard infinitiveTo verbRead.

En primer lugar:

Ya sabes, es una empresa de ingeniería, por lo que los estilos de codificación no importan mientras los algoritmos sean sólidos.

Los estilos de codificación son importantes independientemente de la empresa. Sí, los algoritmos deben ser sólidos, pero el código debe ser mantenible por todos, no solo por el desarrollador original. Tener un estándar de codificación que incluya elementos de estilo sirve para lograrlo. No digo que todo el código deba tener un estilo idéntico, eso sería contraproducente, pero debería haber un cierto grado de coherencia.

Ahora en notación húngara:

Si bien tenía sus usos, con un IDE moderno que admite comportamientos de tipo IntelliSense, no es necesario incluir el tipo de la variable en su nombre. Esta información está disponible para usted de otras maneras. En el peor de los casos, puede hacer que el código sea más difícil de leer si tiene que cambiar el tipo de variable en el futuro.

No lo uses Es redundante y hace que el código sea más difícil de leer.

Gran parte del debate sobre la notación húngara (sistema) depende del área de trabajo. Solía ​​estar muy firmemente del lado de "¡de ninguna manera!", Pero después de haber trabajado durante algunos años en una empresa donde se utiliza para el desarrollo integrado, puedo ver algunas ventajas en ciertas aplicaciones y definitivamente ha crecido en mí. .

Sistemas húngaros

Por lo que puedo decir, Systems Hungarian tiende a usarse mucho en el campo incrustado. En aplicaciones de PC, el compilador tratará muchos de los problemas asociados con las diferencias entre (por ejemplo) cadenas, enteros y valores de coma flotante. En una plataforma profundamente integrada, a menudo le preocupan las diferencias entre enteros sin signo de 8 bits, enteros con signo de 16 bits, etc. El compilador (o incluso la pelusa con las reglas de MISRA impuestas) no siempre detecta estos. En este caso, tener nombres de variables como u8ReadIndex, s16ADCValuepuede ser útil.

Apps Hungarian

Apps Hungarian tiene ventajas definitivas cuando se trata de aplicaciones de PC / Web, por ejemplo, ofrece una diferencia visual entre cadenas 'inseguras' y cadenas 'seguras' (es decir, aquellas ingresadas por un usuario y aquellas que se han escapado o leído de recursos internos o lo que sea ) El compilador no tiene conocimiento de esta distinción.

¿Cuál es el punto de?

El uso de (Sistemas o Aplicaciones) húngaro se trata de hacer que el código incorrecto parezca incorrecto .

Si está copiando una cadena insegura directamente en una cadena segura sin escapar, se verá mal si usa Apps Hungarian.

Si está multiplicando un entero con signo por un entero sin signo, el compilador promocionará (a menudo en silencio) el firmado a (uno posible enorme) sin signo, lo que posiblemente resulte en un error: Systems Hungarian hace que esto parezca incorrecto.

En ambas situaciones, la notación húngara (Aplicaciones / Sistemas) tiende a hacer que las revisiones formales de códigos sean más rápidas, ya que hay menos referencias al tipo de la variable.

En general

En general, mi opinión es que lo más importante es que tienes un estándar de codificación. Ya sea que use Systems Hungarian, Apps Hungarian o ninguno de ellos es una cuestión de preferencia personal o grupal, al igual que la elección de los tipos de sangría, etc. Sin embargo, hay ventajas definitivas para que todo el equipo de desarrollo trabaje con la misma preferencia.

El propósito de la notación húngara es codificar información en el identificador que de otro modo no puede codificarse en el sistema de tipos. Mi propia opinión es que si esta información es lo suficientemente importante como para codificarse, entonces es lo suficientemente importante como para codificarse en el sistema de tipos, donde puede verificarse correctamente. Y si la información no es importante, ¿por qué diablos quieres desordenar tu código fuente con ella?

O, para decirlo de manera más sucinta: la información de tipo pertenece al sistema de tipos. (Nota: no tiene que ser un sistema de tipo estático . Siempre que detecte los errores de tipo, no me importa cuándo los detecte).

Un par de otras respuestas mencionaron las Unidades de medida como usos aceptables de la notación húngara. (Estoy un poco sorprendido de que nadie haya mencionado el Orbitador Climático de Marte de la NASA todavía, ya que eso parece aparecer todo el tiempo en las discusiones sobre la notación húngara).

Aquí hay un ejemplo simple en F #:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

Mira, mamá, ¡no hay húngaros!

Si yo fuera a utilizar la notación húngara en lugar de tipos aquí, que no me ayudaría un bit:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

El compilador lo dejó pasar. Ahora estoy confiando en un humano para detectar lo que es esencialmente un error tipográfico. ¿No es eso para lo que es un corrector de tipo?

Aún mejor, usando el lenguaje de programación Frink :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

Entonces, en resumen: no me gusta la notación húngara. Nunca deberías usarlo.

Dicho esto, creo que usar la notación húngara es una buena idea. ¿Esperar lo?

¡Sí! En este caso particular , mencionaste:

Además, la mayor parte de nuestro código tiene que ejecutarse en algunos DSP raros, donde un concepto como bool o float no existe de todos modos

¡Pero ese es precisamente el único caso de uso sensato para la notación húngara!

PD: Recomiendo sinceramente mirar a Frink. Su manual contiene algunos de los chistes de pedo más increíbles de la historia. También es un lenguaje genial :-)

No tiene sentido en un lenguaje orientado a objetos: todo es un tipo que es evidente cuando se trata de usarlo.

El único lugar donde Systems Hungarian se busca es con un lenguaje débilmente tipado como C. Es doblemente importante con C porque no hay un objeto explícito (tiene estructuras, pero todas las funciones son externas a la estructura). En algo más fuertemente tipado como C ++, Java y C # no ayuda, y de hecho empeora las cosas. El código cambia, y es mucho más fácil cambiar un tipo que cambiar todos los lugares donde está usando un nombre de variable. También es un trabajo ocupado innecesario que tiende a ser ignorado.

Si tiene unidades de medida, puede ser útil codificar eso en un nombre, pero al final eso también puede ser ruido adicional. Por ejemplo, declararemos la unidad de medida estándar para las diferentes cosas con las que estamos trabajando en nuestro código. Por ejemplo, ¿estamos utilizando gradientes o grados, metros o pies, marcos o milisegundos? Una vez que se establece el estándar para el código, cada vez que leemos en una unidad de medida, siempre convertimos inmediatamente a la unidad de medida estándar para el código.

Mi consejo : comience con sus puntos débiles actuales y elija un estándar razonable para esa parte del código. La especificación excesiva de un estándar de codificación es contraproducente. Es muy valioso tener nombres de variables y campos que deletreen lo que representan, y la mayoría de las veces se puede inferir con seguridad el tipo del concepto.

¡DIABLOS NO!

No use la notación húngara ni ninguna otra notación. Como programadores, no deberíamos estar usando "notación" para nuestros nombres de variables.

Lo que debemos hacer es nombrar bien nuestras variables :

• Evita los nombres demasiado generales. No lo nombre zcuando es una variable de clase que representa un objeto con nombre, por ejemplo, una factura telefónica. Llámalo phoneBillo PhoneBill.

• Evita nombres demasiado específicos. Cuando algo está claro sin información adicional, no lo incluya. Si es solo una variable de índice de cadena para recorrer los caracteres de una cadena, y solo la usa una vez en la función MyFunc, ¿por qué alguna vez la llamaría MyFuncTempStringCharacterIndex? Eso es una broma triste. Llámalo Poso incluso isi quieres. En contexto, el próximo programador comprenderá fácilmente lo que significa.

• Al centrarse en cuán general o específico debe ser un nombre, tenga en cuenta el dominio en el que se encuentra y el contexto de otros posibles significados. En el caso estrecho donde hay dos elementos de tipo similar, fácilmente confundidos, que se usan de la misma manera, entonces está bien encontrar un prefijo o sufijo para denotar esa diferencia. Mantenlo lo más corto posible.

Como han dicho otros respondedores, es este caso estrecho el que inició "Apps Hungarian", para distinguir entre mediciones relativas a la ventana rwTabPositiony al documento rdTabPosition. Pero en una aplicación que hace todo lo relacionado con el documento, ¡no agregue nada extra! De hecho, ¿por qué no usar la idea de Jörg W Mittag? de de hacer un nuevo tipo real con él? Entonces no puedes confundir las cosas.

En casi cualquier área, agregar cosas que tengan una densidad de significado mínima reduce el significado general y la facilidad de comprensión. Aquí hay un ejemplo de Ben Franklin . Y otro ejemplo: es posible en inglés decorar nuestras palabras con su parte del discurso. Es más información, ¿no? En caso de que los principiantes al inglés se confundieran, podría ser realmente útil para ellos, ¿verdad? Lea esto y dígame lo útil que cree que es esto para la comprensión a largo plazo y la transmisión eficiente de información:

vrbDo advnot vrbuse nouHungarian nounotation cnjor adjany adjother nounotation. Como programadores de programación, no deberíamos ver nouusing "nounation" prpfor proou novariames adjvariable.

Al agregar información, hice que fuera un completo dolor leerlo.

Así que olvida la notación. Olvida los prefijos especiales que siempre agregas. En mi opinión, la única pauta real aquí debería ser:

Mantenga los nombres de las variables lo más cortos posible, tan significativos como sea necesario y siempre sin ambigüedades .

El propósito de un identificador es más importante que su tipo. Si usa nombres descriptivos para identificadores en sus programas, no necesita usar anotaciones húngaras. isConnectedsiempre es más legible y fácil de entender que boolConnected.

Utilizamos el húngaro cuando era programador en C ++, y fue genial. Puede ver el tipo de una variable (por ejemplo, BSTR, CString, LPCTSTR o char *) sin buscar la declaración. En esos días, buscaría la declaración haciendo:

1. ctrl-home
2. Ctrl-F
3. nombre de la variable
4. entrar

Entonces importaba bastante. Pero alrededor del año 2000, sucedieron algunas cosas:

• los editores se volvieron lo suficientemente inteligentes como para mostrar el tipo de variable como información sobre herramientas
• los editores tenían un acceso directo a "ir a la declaración" y una forma rápida de navegar hacia atrás
• C ++ se usó menos, y la mayoría de los otros lenguajes tienen tipos menos variables. Por ejemplo, en C #, está bastante seguro de que lastNamees un System.String, porque solo hay una clase de cadena.

Fui uno de los últimos en cambiarme del húngaro, y ahora cuando leo el código fuente antiguo, en realidad me molesta.

Simplemente odio la notación húngara, prefiero usar guiones bajos para delimitar nombres de variables.

Además de eso, cuando pones el tipo como primera letra al comienzo de tu nombre de variable de esta manera: float fvelocity; vect vDirection; string ** ppszWord;

el autocompletado los clasifica a todos, y tiene problemas para encontrar lo que desea, y las personas tienden a usar lo que piensan que es mejor, y ya no es una notación.

Simplemente me gusta escribir ThingsLikeThat cuando necesito ser muy descriptivo sobre la variable, porque ahorra espacio y el hecho de que haya mayúsculas lo hace más legible.

Lo que suelo hacer es nombrar mis métodos y clases con la primera letra en mayúscula y minúscula para los nombres de las variables, y un guión bajo para los nombres de las variables (este último me parece útil).

En serio, prefiero que las personas se preocupen por esas reglas: use comas, aritmética y llaves con espacios relevantes:

void f(int a, char b);
int a = b + 4 / (3 + 4);

No más de 80 caracteres por línea, o MÁS DE 90 caracteres, use argumentos de varias líneas para funciones o long if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

De acuerdo con la mayoría, es un estilo antiguo.

Con los IDE modernos, un desplazamiento rápido sobre una variable muestra el tipo.