¿Por qué no debería utilizar la "notación húngara"?
Sé a qué se refiere el húngaro: dar información sobre una variable, parámetro o tipo como prefijo de su nombre. Todo el mundo parece estar furiosamente en contra, aunque en algunos casos parece una buena idea. Si siento que se está impartiendo información útil, ¿por qué no debería ponerla allí donde esté disponible?
Ver también: ¿La gente utiliza las convenciones de nomenclatura húngaras en el mundo real?
vEl uso de la notación húngara adj dificulta la lectura del código n.
Sep 21 '2008 20:09
La mayoría de la gente utiliza la notación húngara de forma incorrecta y obtiene resultados incorrectos.
Lea este excelente artículo de Joel Spolsky: Hacer que el código incorrecto parezca incorrecto .
En resumen, la notación húngara en la que antepone los nombres de las variables con su type(cadena) (Sistemas húngaros) es mala porque es inútil.
La notación húngara, tal como fue concebida por su autor, donde se antepone el nombre de la variable con su kind(usando el ejemplo de Joel: cadena segura o cadena insegura), las llamadas aplicaciones húngaras tienen sus usos y siguen siendo valiosas.
Joel está equivocado y he aquí por qué.
Esa información de "aplicación" de la que habla debe estar codificada en el sistema de tipos . No debe depender de invertir los nombres de las variables para asegurarse de no pasar datos inseguros a funciones que requieren datos seguros. Deberías convertirlo en un error de tipo, para que sea imposible hacerlo. Cualquier dato no seguro debe tener un tipo marcado como no seguro, de modo que simplemente no pueda pasarse a una función segura. Para convertir de inseguro a seguro debería requerirse un procesamiento con algún tipo de función de desinfección.
Muchas de las cosas de las que Joel habla como "clases" no son clases; son, de hecho, tipos.
Sin embargo, lo que falta en la mayoría de los lenguajes es un sistema de tipos que sea lo suficientemente expresivo como para imponer este tipo de distinciones. Por ejemplo, si C tuviera una especie de "typedef fuerte" (donde el nombre typedef tuviera todas las operaciones del tipo base, pero no fuera convertible a él), entonces muchos de estos problemas desaparecerían. Por ejemplo, si pudiera decir, strong typedef std::string unsafe_string;introducir un nuevo tipo unsafe_stringque no pueda convertirse en std::string (y que por lo tanto pueda participar en la resolución de sobrecarga, etc., etc.), entonces no necesitaríamos prefijos tontos.
Entonces, la afirmación central de que el húngaro es para cosas que no son tipos es errónea. Se utiliza para información de tipo. Ciertamente, información de tipo más rica que la información de tipo C tradicional; es información de tipo que codifica algún tipo de detalle semántico para indicar el propósito de los objetos. Pero sigue siendo información de tipos, y la solución adecuada siempre ha sido codificarla en el sistema de tipos. Codificarlo en el sistema de tipos es de lejos la mejor manera de obtener una validación y aplicación adecuadas de las reglas. Los nombres de las variables simplemente no son suficientes.
En otras palabras, el objetivo no debe ser "hacer que el código incorrecto parezca incorrecto para el desarrollador". Debería ser "hacer que el código incorrecto parezca incorrecto para el compilador ".
