¿Cuál es el atractivo de Systems Hungarian? [cerrado]

¿ En qué pautas de nombres sigues? , el autor dice:

También prefiero codificar usando la notación húngara de Charles Simonyi.

Me he encontrado con varios programadores que todavía prefieren usar húngaro, principalmente del sabor Petzold / Systems Hungarian. Piense dwLength = strlen(lpszName).

He leído Hacer que el código incorrecto parezca incorrecto , y entiendo la lógica de las aplicaciones húngaras, donde se incluye información de tipo de dominio en los nombres de las variables. Pero no entiendo el valor de adjuntar el tipo de compilador al nombre.

¿Por qué los programadores aún persisten en usar este estilo de notación? ¿Es solo inercia? ¿Hay algún beneficio que supere la menor legibilidad? ¿Las personas simplemente aprenden a ignorar a los decoradores cuando leen el código y, de ser así, cómo continúan agregando valor?

EDITAR: Muchas respuestas explican la historia, o por qué ya no es relevante, las cuales están cubiertas en el artículo que cité.

Realmente me gustaría saber de alguien que todavía lo usa. por que lo usas? ¿Está en tu estándar? ¿Lo usarías si no fuera necesario? ¿Lo usarías en un nuevo proyecto? ¿Qué ves como las ventajas?

En este momento todavía uso el húngaro por exactamente tres razones , evitándolo juiciosamente por todo lo demás:

1. Para ser coherente con una base de código existente al hacer mantenimiento.
2. Para controles, p. Ej. "txtFirstName". A menudo necesitamos distinguir entre (por ejemplo) "firstName" el valor y "firstName" el control. Húngaro proporciona una forma conveniente de hacer esto. Por supuesto, podría escribir "firstNameTextBox", pero "txtFirstName" es igual de fácil de entender y tiene menos caracteres. Además, usar húngaro significa que los controles del mismo tipo son fáciles de encontrar y, a menudo, se agrupan por nombre en el IDE.
3. Cuando dos variables tienen el mismo valor pero difieren según el tipo. Por ejemplo, "strValue" para el valor realmente escrito por el usuario e "intValue" para el mismo valor una vez que se ha analizado como en un entero.

Ciertamente no quisiera establecer mis ideas como mejores prácticas, pero sigo estas reglas porque la experiencia me dice que el uso ocasional de la capacidad de mantenimiento del código de beneficios húngaro, pero cuesta poco. Dicho esto, reviso constantemente mi propia práctica, por lo que bien podría hacer algo diferente a medida que se desarrollen mis ideas.

Actualizar:

Acabo de leer un artículo perspicaz de Eric Lippert, que explica cómo el húngaro puede ayudar a que el código incorrecto parezca incorrecto. Vale la pena leerlo.

No soy un gran fanático del uso de la notación húngara, pero pienso de esta manera:

• También podemos notar que es más rápido encontrar una cadena que se refiera a un cuadro de texto en su código: escribiendo "txt" en su cuadro de búsqueda.

No imagine lo contrario, donde cada elemento tiene su propio nombre. Puede ser más lento para ti encontrar a dónde quieres ir, ¿verdad?

Lo mismo ocurre con ddl cuando queremos referirnos a una DropDownList, ¿es más fácil o no? :)

La gente no pasará tanto tiempo para encontrar dónde está este elemento.

El uso del prefijo no es utilizable para compiladores de lenguajes modernos como C #, pero es utilizable (legible) para los seres humanos.

Las aplicaciones húngaras (etiquetas para denotar propiedades semánticas de objetos que no se pueden expresar a través del sistema de tipos) eran una forma razonable de tratar algunos errores comunes cuando se usaban los idiomas de tipo débil de principios de los años ochenta. Sirven de poco propósito en los idiomas fuertemente tipados de hoy.

Los sistemas húngaros (etiquetas para denotar de forma redundante el tipo declarado de un objeto) nunca han tenido ningún propósito, excepto imponer una apariencia superficialmente uniforme en una base de código. Fue creado y propagado por gerentes no técnicos y programadores sin experiencia, que entendieron mal la intención de Apps Hungarian, y creían que la calidad del código podría mejorarse mediante pautas de codificación complejas.

Ambos estilos se originaron dentro de Microsoft. En estos días, las convenciones de nomenclatura de Microsoft dicen categóricamente "No use la notación húngara".

Si encuentra el sistema correcto de prefijos, podría extender el desgaste de sus teclas, lo que reduciría el gasto en teclados de reemplazo.

Supongo que podría ampliar esto. He usado SH en mi lugar de trabajo durante los últimos diez años más o menos (porque está en nuestro estándar). Nunca ha ayudado a resolver un problema.

Por otro lado, he usado variables sin adornos pero bien nombradas en mi 'código de inicio' durante casi el mismo tiempo. Nunca he extrañado SH.

En ambos lugares, he escrito un código de protocolo que requiere tipos primitivos de tamaño fijo. Este es el caso de uso más beneficioso que se me ocurre para SH. No me ha ayudado saberlo cuando se escribe con SH, y no me ha impedido cuando se escribe sin SH.

Entonces, en conclusión, la única diferencia que puedo ver es el desgaste de su teclado.

De hecho, comencé a usar SH en el nuevo código que escribí este mes.

Mi tarea consistió en reescribir algún código de Perl en JS para que pudiera moverse al lado del cliente de nuestra aplicación web. En Perl, generalmente no se requiere SH debido a los sigilos ($ string, @array,% hash).

En JavaScript, encontré que SH es invaluable para rastrear los tipos de estructuras de datos. Por ejemplo,

var oRowData = aoTableData[iRow];

Esto recupera un objeto de una matriz de objetos utilizando un índice entero. Cumplir con esta convención me ahorró bastante tiempo buscando tipos de datos. Además, puede sobrecargar los nombres de variables sucintos ( oRowvs. iRow).

tl; dr: SH puede ser genial cuando tienes código complejo en un lenguaje débilmente tipado. Pero si su IDE puede rastrear tipos, prefiera eso.

También tengo curiosidad por ver la justificación. Sabemos por qué lo usaron en el pasado: falta de soporte IDE para la información de tipo. ¿Pero ahora? En pocas palabras, creo que es una tradición. El código C ++ siempre se veía así, entonces, ¿por qué cambiar las cosas? Además, cuando construyes sobre el código anterior que usaba la notación húngara, se vería bastante extraño cuando de repente dejas de usar eso ...

La notación húngara de Sistemas fue, de hecho, un poco confusa, un malentendido del término "tipo". Los desarrolladores de sistemas lo tomaron literalmente como el tipo de compilador (palabra, byte, cadena, ...) en lugar del tipo de dominio de aplicaciones (índice de fila, índice de columna, ...).

Pero supongo que cada desarrollador pasa por varias fases de estilo que parecen una gran idea en ese momento (y el tipo de prefijo parece una buena idea para un novato) antes de caer en las trampas (cambiar el tipo, crear nuevos prefijos significativos) etc) Así que supongo que hay una inercia: de los desarrolladores que no mejoran y se dan cuenta de por qué es una mala elección, de los desarrolladores atados a los estándares de codificación que exigen la práctica y de las personas que usan <windows.h>. Sería demasiado costoso para Microsoft cambiar para deshacerse de la notación de prefijo (que es incorrecta en muchos lugares: ¿WPARAM?).

Hay una cosa que la gente falta con el húngaro. La notación húngara en realidad funciona GENIAL con autocompletar.

Digamos que tiene una variable y el nombre es intHeightOfMonster.

Digamos que olvidas el nombre de la variable

Podría ser heightOfMonster o MonsterHeight o MeasurementMonsterHeight

Desea poder escribir una letra y hacer que el autocompletado le sugiera algunos nombres de variables.

Sabiendo que heightOfMonster es un int, solo tienes que escribir i y listo.

Ahorrar tiempo.