Oposición a la nomenclatura húngara

La nomenclatura húngara es una convención de nomenclatura de programación. Las convenciones de nomenclatura son los aspectos más importantes y controvertidos de las convenciones de redacción de programas. Han sido un campo de batalla entre los estrategas militares desde la antigüedad. ¿Para qué sirven las convenciones de nomenclatura? Cuatro palabras: Justificable. Usando una dicotomía, las convenciones de nomenclatura se dividen en buenas y malas convenciones de nomenclatura, es decir, convenciones de nomenclatura que están justificadas y convenciones de nomenclatura que no están justificadas. Los buenos zapatos de baile son aquellos que hacen que los bailarines sientan su presencia, mientras que los malos zapatos de baile hacen que los bailarines bailen con grilletes. Una mala convención de nomenclatura puede ser mucho más destructiva de lo que una buena convención de nomenclatura puede ser creativa.

Algunas personas piensan que la nomenclatura húngara es una mala convención de nomenclatura. Dar ejemplos. Tomando como ejemplo los lenguajes de programación estáticamente fuertemente tipados, las plantillas de análisis son el lenguaje C y el lenguaje C ++. El método húngaro siguiente es la abreviatura de la nomenclatura húngara. Los beneficios de la nomenclatura húngara son ambiguos e impredecibles.

Plantilla 1: strcpy(pstrFoo,pcstrFoo2) Vs strcpy(foo,foo2)

Ningún programador admitirá que no conoce el tipo de parámetro de la función strcpy, por lo que la ganancia es cero.

Plantilla 2: Unknown_function(nFoo) Vs Unknown_function(foo)

Aún no hay ningún beneficio. Para una función cuyo tipo se desconoce, el programador debe consultar la documentación de la función, lo cual supone un coste. La única ventaja de utilizar el método húngaro es que la persona que lee el código sabe que la función requiere un parámetro entero, lo cual no sirve de nada. Una función es una interfaz y los tipos de parámetros son solo una pequeña parte de la interfaz. Aún se debe consultar en la documentación información importante como funciones funcionales, información de salida, seguridad de subprocesos, seguridad de excepciones, legalidad de parámetros, etc.

Plantilla 3: nFoo=nBar Vs foo=bar

La única ventaja de usar el método húngaro es que las personas que leen el código saben que aquí se produce una copia de una variable entera, lo cual suena como nada. Problema, puedes estar seguro. Si lo que ve es nFoo=szBar, no puede estar seguro. Pero ese no es el caso. Lo primero que falla debería ser el compilador. Por otro lado, nFoo=nBar sólo es gramaticalmente legal. Lo que realmente le importa a la gente que mira el código es la legalidad semántica, y la ley húngara no ayuda con esto. Por otro lado, un buen escritor seguirá conscientemente una regla: es apropiado tener una o dos variables temporales en la unidad organizativa más pequeña del código, si hay más de tres, deben reorganizarse. Combinado con la primera regla mencionada anteriormente, se puede concluir que el código fácil de entender debería ser fácil de entender. Esta es la alta calidad incorporada del código. Las buenas convenciones de nomenclatura tienen un beneficio limitado para la calidad integrada, mientras que las malas convenciones de nomenclatura dañan más la calidad integrada de lo que la gente piensa. La nomenclatura húngara es difícil de implementar en lenguaje C y no se puede implementar en lenguaje C++.

El método húngaro es la redundancia del sistema de tipos, por lo que la clave para implementar el método húngaro es si podemos copiar con precisión el sistema de tipos. Depende de la complejidad del sistema de tipos.

Lenguaje C:

1. Tipos integrados: int, char, float, doble copia en n, ch, f, d? Parece que no hay ningún problema. Pero cómo expresar nulo, la ley húngara no puede hacerlo.

2. Tipo de combinación: matriz, unión, enumeración, estructura copiada a a, u, e, s? No es conveniente.

La dificultad aquí no es nombrar el tipo principal, sino nombrar el subtipo. ¿An representa una matriz de números enteros? sfoo,sbar significa estructura foo, barra de estructura? ¿Ausfoo representa la estructura de unión foo array? Muy detallado.

3. Tipo especial: puntero. En teoría, el puntero debería ser un tipo compuesto, pero puede considerarse un tipo integrado en el lenguaje C, porque el lenguaje C no distingue estrictamente entre diferentes tipos de puntero.

Lenguaje C++:

1. clase: si la estructura en lenguaje C puede ser manejada por stru, no sueñes con usar cls para manejar la clase en C++.

Estrictamente hablando, la clase no es un tipo en absoluto, sino una herramienta para crear tipos. En C++, la cantidad de tipos integrados en el lenguaje es completamente insignificante en comparación con la cantidad de tipos definidos por el usuario creados por clase. stdvectorFoo representa la variable de tipo vectorial de biblioteca estándar Foo, lo cual es ilógico.

2. Espacio de nombres: boostfilesystemiteratorFoo, lo que significa que la variable de tipo de directorio Foo atravesada por el subespacio del sistema de archivos de boost space aún no es factible.

3. Plantilla: std::map ¿Cuál es el nombre exacto del tipo?

4. Parámetros de plantilla: plantilla const T& max(const T& a, const T& b, BinaryPredicate comp) Este se nombra usando la nomenclatura húngara, lo cual es extremadamente difícil.

5. Modificación de tipo: estática, externa, mutable, registro, volátil, constante, corta, larga, sin firmar. Agregar modificación de tipo lo hace aún más difícil.

La nomenclatura húngara tiene sus ventajas pero también sus desventajas, lo que nos obliga a utilizar sus fortalezas y evitar sus debilidades y aplicarla racionalmente.

/css/tongji.js">