¿Sigue siendo la notación húngara de sistemas una práctica útil? [cerrado]

Busqué en el foro, pero no pude encontrar las respuestas por qué debería evitarse, solo por qué no es una bala de plata. Entonces no creo que esta pregunta sea un duplicado.

¿Hay un VÁLIDO razón por la que debería olvidar Sistemas de Hungría Estoy acostumbrado a?

Hasta ahora veo los siguientes beneficios al usarlo:

• Nomenclatura variable constante
• Verá el tipo sin buscar (intellisense está muerto / indexando la mitad del tiempo, por lo que sigue siendo un motivo válido)
• La semántica todavía se puede empaquetar en la segunda parte del nombre

Y siguientes inconvenientes:

• Molesta a algunas personas (no tengo idea de por qué)
• Si se cambia el tipo, es posible que el tipo no coincida con el nombre de la variable (no creo que sea una razón válida, los tipos se cambian raramente y usted tiene "cambiar el nombre de todo")

Entonces por qué:

vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.push_back(strCity);

es peor que:

vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?

Solía ​​usarlo (hace muchos años) y ya no. La razón principal es que es superfluo en los lenguajes OO con tipeo fuerte (C ++, Java) que utilizo la mayor parte de mi carrera. En estos idiomas, si defino bien mis tipos, el compilador puede y hará cumplir la seguridad de tipos para mí. Por lo tanto, los prefijos de nombres son solo un desorden que hace que los nombres sean más largos, por lo que es más difícil de leer y buscar.

En cualquier programa OO bien escrito, la mayoría de sus variables son (referencias a) tipos definidos por el usuario. Si los antepone con la misma etiqueta general (como o"objeto"), no obtendrá ningún beneficio, solo los inconvenientes. Sin embargo, si los prefijas con etiquetas de tipo específico, te encuentras en un laberinto de tratar de encontrar abreviaturas diferentes para miles de tipos diferentes con nombres a menudo similares *, y recordar cambiarlos todos cuando un tipo o nombre cambia (que es no es raro en absoluto en un programa bien mantenido).

Por supuesto, esto no se aplica a los idiomas que no son OO, y puede que no se aplique a los idiomas de tipo débil y / o dinámico (no tengo experiencia con estos, aparte de C). Ni a editores / IDE subóptimos sin un IntelliSense utilizable (o su equivalente local). Y esto es solo mis 2 centavos. Entonces, si la notación húngara funciona para su equipo y su proyecto, hágalo. Lo importante es ponerse de acuerdo en esto (así como en un estilo de codificación consistente en general) antes de que comience el proyecto, y mantenerlo consistente en todo momento.

* _{A una corta lista de nuestro proyecto actual: tenemos Charge, ChargeBreakdown, ChargeCalculator, ChargeDAO, ChargeDTO, ChargeLineHelper, ChargeMaps, ChargePairy ChargeType, entre otros. Además, también tenemos Contracts, Countries, Checkouts, Checkins ... y esta es solo la letra C, en un proyecto que probablemente ni siquiera sería llamado "de tamaño razonable" por el OP.}

Descargo de responsabilidad: en realidad soy húngaro, así que creo que puedo hablar sobre este tema con autoridad ;-)

¿Por qué es std::vector<string> vecCityNames;malo?

El problema con la notación húngara, ya que generalmente se usa, es que, si el perfil muestra que los nombres de las ciudades deberían mantenerse en un std::deque, todos los nombres de variables que se refieren a un objeto de ese tipo de repente tendrán un nombre engañoso.

¿Va a cambiar el nombre de todas sus variables? ¿Alguna vez has tratado de hacer eso en un gran proyecto? Con la ayuda de Murphy (y el tipo es increíblemente útil allí), alguien en alguna parte seguramente habrá usado variables llamadas algo así deqCityNames, haciendo que tus cambios rompan la construcción, dejándote sentado durante horas jugando con el código que, durante media década, nadie se atrevió a mirar en, por miedo a ser mordido por una bestia venenosa.

Sin embargo, por lo que sé, por la forma en que Charles Simonyi ideó el húngaro, el prefijo denotaba el uso semántico de las variables , en lugar de su tipo sintáctico . Es decir, el prefijo apropiado para su lista de nombres de ciudades, sin importar en qué tipo se implemente, probablemente sea listCityNames(o lstCityNames, si listno es lo suficientemente críptico para usted).

Pero considero que el prefijo es superfluo, porque el plural ("nombres") ya transmite que se trata de un montón de ciudades. En pocas palabras: cuando elige sus identificadores con cuidado, la notación húngara rara vez se necesita. OTOH, la forma en que se usa comúnmente es, a la larga, realmente dañar el código.

Por alguna razón, las respuestas existentes aquí parecen estar bailando en torno a la justificación de la notación húngara, sin decirlo directamente. La notación húngara es útil para agregar información de tipo (en un sentido teórico de tipo ) cuando sería difícil hacerlo en el idioma mismo . Como suele suceder, no es tan difícil usar C ++ o el sistema de tipos de Java de tal manera que la notación húngara (como se describe generalmente) es completamente superflua, y esto es probablemente lo que ha llevado a la reacción violenta en su contra: agrega trabajo del programador para mantener esas anotaciones en todas nuestras variables naes, pero proporciona poco o ningún valor adicional (e incluso puede causar daño, ya que el código parece más desordenado).

Por otro lado, si uno restringe el uso de la notación húngara para escribir información (nuevamente, en un sentido teórico de tipo ) que no esnaturalmente encapsulado por el lenguaje, entonces puede ser muy útil. Por ejemplo, C y C ++ pasan referencias de matriz como tipos de puntero, pero las referencias de matriz y los punteros tienen diferentes operaciones que deben realizarse contra ellos: las matrices se pueden indexar más allá del primer elemento, mientras que los punteros no. Esta es información útil que se pierde en el sistema de tipos tan pronto como se pasa una matriz a una función como argumento. Como tal, en nuestro grupo hemos adoptado anotaciones de nombre de variable en código C y C ++ para distinguir si una variable de puntero es en realidad un puntero a un solo elemento o un puntero a una matriz. La adopción de esta convención ha sido en parte responsable de una gran reducción en la ocurrencia de problemas de corrupción de memoria en nuestra base de código.

Molesta a algunas personas (no tengo idea de por qué)

La razón por la que me molesta es que es un pequeño aumento de velocidad en cada identificador que ralentiza mi escaneo visual del código. ES mAs SI PUEDE KHAD Z PARA q LEER EL CONTENIDO EN INGLÉS COMO TU ESTO.

Odio es una palabra demasiado fuerte, OMI. Puede escribir su código de la forma que desee; Simplemente prefiero no usar la notación húngara en mi propio código, y dado una opción, también preferiría no tener que leerlo o trabajar con él en el código de otras personas.

Usted preguntó por qué algunas personas encuentran molesta la notación húngara. No puedo hablar por los demás, pero las razones que me molestan son:

1. Es feo Húngaro toma nombres perfectamente razonables y antepone lo que equivale a un código. Una vez que haya internalizado este código, estoy seguro de que tiene mucho sentido, pero para los no iniciados, parece que alguien desató el nombre de C ++ en mi código fuente.

2. Es redundante La declaración de una variable establece su tipo; No siento la necesidad de repetir esa información en el nombre de la variable. Esto no es cierto en todos los idiomas: en Perl, por ejemplo, los sigilos como @ o $ antepuestos al nombre de la variable esencialmente definen el tipo de la variable, por lo que no tiene más remedio que usarlos.

3. Resuelve un problema que no tengo. Los métodos y las funciones no deberían ser tan largos que tenga que buscar mucho para encontrar la declaración de una variable o parámetro local, y no deberían involucrar tantas variables que tenga problemas para hacer un seguimiento de qué es qué. Declarar variables locales cercanas al código que las usa también ayuda a este respecto. Los compiladores de C del pasado requerían que todas las variables locales se declararan al comienzo de la función, pero esa limitación se eliminó hace mucho tiempo.

4. Esta incompleto. La notación húngara se inventó para un idioma (BCPL) que no tenía un sistema de tipos, y luego se usó ampliamente en un idioma (C) que tenía un número bastante limitado de tipos nativos. En mi opinión, no funciona bien con lenguajes como C ++ o Java que tienen sistemas de tipos extensos. ¿Por qué querría usar un prefijo para indicar el tipo de una variable que es nativa, como char [], pero no una que sea una clase? Alternativamente, si comienzo a inventar prefijos como vecpara clases, terminaré con una gran jerarquía de prefijos paralelos a mi jerarquía de clases. Si eso te atrae, eres bienvenido; solo pensarlo me da dolor de cabeza.

5. Es ambiguo , al menos como lo entiendo. ¿Cuál es la diferencia entre szFooy pszFoo? El primero es una cadena terminada en cero, y el segundo es un puntero a una cadena terminada en cero. Pero en C o C ++, hasta donde yo sé, cualquier variable de cadena es efectivamente un puntero, entonces, ¿son iguales o no? ¿Cuál debería usar? La respuesta real realmente no importa: el punto es que no puedo discernir la respuesta usando la misma notación que se supone que me ayuda a evitar este tipo de preguntas. La declaración de la variable, por otro lado, tiene que ser inequívoca porque es lo que usa el compilador.

Esas son las cosas que me molestan sobre la notación húngara. Sin embargo, incluso como grupo, no creo que expliquen completamente por qué el húngaro ha sido abandonado en gran medida. Estas son las tres razones principales por las que la mayoría de los programadores no usan el húngaro:

1. No hay una razón convincente para usarlo. Vea los artículos 3 y 4 anteriores. Probablemente podría vivir con las molestias si el húngaro ofreciera una gran ventaja sobre no usar el húngaro, pero no veo uno, y aparentemente la mayoría de las otras personas tampoco. Quizás lo mejor del húngaro fue que era una convención ampliamente utilizada, y si se apegaba al uso estándar, podría esperar razonablemente que otros programadores con habilidades similares puedan comprender la notación.

2. Mayor influencia de empresas que no son Microsoft. Probablemente sea justo decir que la mayoría de los programadores que adoptaron la notación húngara lo hicieron porque esa es la forma en que Microsoft escribió el código, y a menudo es más fácil seguir la corriente. Las compañías como Google y Apple tienen esferas de influencia mucho más grandes ahora que en el pasado, y más programadores que nunca están adoptando los estilos de esas compañías y otras que evitan principalmente el húngaro. (Es justo señalar que todavía ve algunos restos, por ejemplo, tanto Google como Apple a menudo usan un prefijo 'k' para nombres constantes).

3. Microsoft mismo ha abandonado el húngaro. Si revisa la sección de Convenciones de nomenclatura general de Microsoft de sus pautas de codificación, encontrará que dice en negrita: No use la notación húngara.

En consecuencia, una razón válida para dejar de usar la notación húngara es:

La popularidad de la notación húngara ha disminuido hasta el punto de que la convención ya no es útil. Muchos menos programadores usan o incluso entienden el húngaro en estos días y, por lo tanto, la convención es mucho menos efectiva para transmitir la información que se supone que debe hacer. Si considera que es una forma útil de escribir código en sus propios proyectos personales, entonces hay pocas razones para detenerse. Sin embargo, si está escribiendo código como parte de un equipo que no usa húngaro, puede convertirse en un muro entre usted y el resto del equipo en lugar de una estrategia de comunicación exitosa.

Hasta ahora veo los siguientes beneficios al usarlo:

• Nomenclatura variable constante

Si nombro todas mis variables después de los personajes de Los Simpson, eso también es consistente, pero ¿es un beneficio?

• Verá el tipo sin buscar (intellisense está muerto / indexando la mitad del tiempo, por lo que sigue siendo un motivo válido)

Esta es la única razón válida, basada en la debilidad de una herramienta específica ...

• La semántica todavía se puede empaquetar en la segunda parte del nombre

Eso no es un beneficio; simplemente estás reclamando la ausencia de una desventaja ( masiva ).

El IDE me dirá trivialmente cuál es el tipo de variable cuando pase el mouse sobre ella. Entonces, ¿por qué molestarse en duplicar esa información? Fundamentalmente, la notación húngara de sistemas es una violación de DRY, con todos los escollos asociados. Cuando esa información es accesible de manera trivial en un entorno moderno, no hay razón para pagar ese precio.

La consistencia no es una ventaja en sí misma. No nombrarlos con el tipo también es consistente. Solo tendría inconsistencia si solo algunas variables tuvieran sus tipos en el nombre. Y agrupar la semántica en la segunda parte es simplemente "Bueno, no es tan malo", todos los demás usan el nombre completo para la semántica. No tienes ninguna ventaja real en la lista.

Otro punto con las formas tradicionales de notación húngara es que generalmente son prefijos. Hay 2 problemas en mi humilde opinión aquí:

1) Un lector humano generalmente quisiera la información más importante primero, en la mayoría de las formas de húngaro, la información codificada es posiblemente menos importante que el nombre mismo.

2) Los prefijos efectúan la ordenación léxica, por lo que si, por ejemplo, va a utilizar un prefijo para denotar interfaces o clases y su IDE proporciona una lista ordenada de estas, las clases / interfaces relacionadas se separarán en esta lista.

Claramente, esto se reduce a opiniones, por lo que será difícil trabajar con hechos aquí. Personalmente, me parece que el argumento favor de la notación húngara es un poco escaso en los lenguajes fuertemente tipados y orientados a objetos. En mi experiencia, las aplicaciones OO tienden a manejar la complejidad al mantener las clases coherentes y concisas, y lo mismo se puede decir de las funciones. Esto significa que todas las demás cosas son iguales, terminas con:

• Más clases / tipos
• Métodos más cortos

Ahora, si desea usar la notación húngara, debe decidir si la aplicará en todos los ámbitos, o simplemente usarla para ciertos tipos y clases privilegiados (como las clases de la biblioteca central). Lo último no tiene sentido para mí, y lo primero lleva al "laberinto de tratar de encontrar abreviaturas diferentes para mil tipos diferentes" a los que se refería Péter Török. Esto significa que hay una sobrecarga significativa en el mantenimiento de las listas de abreviaturas y, por lo general, la "denominación variable constante" desaparece.

El segundo punto sobre métodos más cortos significa que, en la mayoría de los casos, no tendrá que pasar por cientos de líneas de código para verificar qué tipo de variable es. Denominar las variables ligeramente más cuidado eliminaría algunas de sus otras preguntas - por ejemplo, cityNamefrente a solo city. Espero quecityName no sea un flotador :)

En cuanto a por qué molesta a las personas, nuevamente, esto probablemente se deba a estar acostumbrado o no. Pero como alguien que no está acostumbrado, puedo decirle que el uso de la notación húngara interrumpe el flujo de código para mis ojos, lo que dificulta la lectura rápida. En resumen, no estoy diciendo que no tiene ningún mérito (aunque no he discutido algunos de sus inconvenientes, en términos de refactorización, etc), estoy diciendo que el esfuerzo no vale la pena, para el tipo fuerte, lenguajes orientados a objetos.

No sé en el contexto de C ++, pero en el mundo Java / C # preferiría tener nombres significativos que transmitan un lenguaje o contexto de dominio que decirme que strFirstNamees una Cadena; Debería ser obvio que es una cadena, o el nombre debe ser refactorizado para transmitir una mejor intención. Si usted requiere un prefijo para saber el tipo de trabajo, diría que su denominación es inconsistente, no lo suficientemente descriptiva o francamente incorrecta. En los idiomas modernos siempre prefiero nombres más largos que no dejan ambigüedad que los nombres vagos o ambiguos.

La única vez que uso húngaro es para controles ASP.NET, y eso es más, IA) no tiene que escribir algo realmente largo como CustomerFirstNameTextBoxversus txtCustomerFirstName, y B) Entonces Intellisense clasificará todos los tipos de control. Sin embargo, me siento "sucio" al hacerlo, aún no he encontrado una mejor manera.

Meh: en realidad se trata de preferencias personales, no importa cuán duro se intente racionalizar sus elecciones. Personalmente me adhiero a la regla "Cuando en Roma ..." y uso húngaro en un código que llama mucho a la API de Windows. Para el código independiente de la plataforma, tiendo a seguir el estilo de la Biblioteca estándar de C ++.

La respuesta se encuentra en esta pregunta: dígame cómo nombrar las siguientes variables:

char * nullTerminatedString;
wchar * nullTerminatedWideString;
string stlString;
wstring stlWideString;
CString mfcString;
BSTR comString;
_bstr_t atlString;

Agregue a estas cadenas constantes, puntero a estos y punteros constantes a estos.

No me gusta la forma de notación húngara que describe. ¿La razón? No sirve ningún punto el 90% del tiempo.

Por ejemplo, un poco de código (equivalente a C ++. Realmente escrito en Delphi) de un proyecto heredado que me veo obligado a soportar:

pRecords[0]->FooMember=10;

... pRecord es una variable, es de tipo TRecordList. TRecordList *pRecords[10];

Es una clase que consiste en una organización llamada FooMember que apunta a fFooMember ... o mFooMember dependiendo de si es un "campo" o un "miembro" (pista: son lo mismo)

¿Problemas? fFooMemberpodría ser algo así como FooMember_ porque siempre accederemos a él a través de la propiedad pública de FooMember. pRecords? Es bastante obvio que es un indicador del hecho de que lo desreferencia por todo el lugar. TRecordList? ¿Cuándo puedes confundir un nombre de tipo y un objeto de ese tipo? El compilador le gritará, y los tipos se usan en casi ningún lugar donde están los objetos (excepto por propiedades / métodos estáticos)

Ahora, hay un lugar donde uso la notación húngara. Esto es cuando se trata con muchas variables de IU que tendrían el mismo nombre que otras variables de IU o variables regulares.

Por ejemplo, si tuviera un formulario para su nombre en él.

Tendría una clase llamada FirstNameForm. Dentro de él, lblFirstName y txtFirstName para la etiqueta y el cuadro de texto respectivamente. Y una propiedad pública FirstName para obtener y establecer el nombre en el cuadro de texto.

Esto también podría resolverse mediante el uso de FirstNameLabel y FirstNameTextBox, pero creo que se tarda mucho en escribir. Especialmente con algo como GenderDropDownList y tal.

Básicamente, la notación húngara es, en el mejor de los casos, molesta a nivel sistemático y, en el peor de los casos, dañina (como las otras respuestas dan sobre problemas de refactorización y consistencia).