¿La mejor manera de deshacerse de la notación húngara?

StackOverflow https://stackoverflow.com/questions/198825

Pregunta

Digamos que ha heredado una base de código C # que usa una clase con 200 métodos estáticos para proporcionar la funcionalidad principal (como las búsquedas en la base de datos). De las muchas pesadillas en esa clase, hay un uso abundante de la notación húngara (el tipo malo).

¿Refactorizaría los nombres de las variables para eliminar la notación húngara, o los dejaría en paz?

Si elige cambiar todas las variables para eliminar la notación húngara, ¿cuál sería su método?

¿Fue útil?

Solución

Solo déjalo en paz. Hay mejores usos de tu tiempo.

Otros consejos

Refactor: encuentro que la notación húngara en esa escala realmente interfiere con la legibilidad natural del código, y el ejercicio es una buena manera de familiarizarse con lo que hay allí.

Sin embargo, si hay otros miembros del equipo que conocen la base del código, necesitará un consenso sobre la refactorización, y si alguna de las variables se expone fuera del proyecto, tendrá que dejarlas en paz.

Haga clic derecho en el nombre de la variable, Refactor - > Renombrar.

Hay complementos VS que también hacen esto, pero el método incorporado funciona bien para mí.

¿Qué haría yo? ¿Asumiendo que solo tengo que mantener el código y no reescribirlo de manera significativa? Déjelo en paz. Y cuando lo haga agregue código, vaya con el estilo existente, es decir, use esa notación húngara fea (tan sucia como eso me hace sentir).

Pero, oye, si realmente tienes un hankerin 'fer refactorin , entonces hazlo poco a poco. Cada vez que trabaja en él, dedique diez minutos a cambiar el nombre de las variables. Poner las cosas en orden un poco. Después de unos meses, es posible que esté limpio como un silbato ...

No olvides que hay dos tipos de notación húngara.

El Charles Simonyi HN original, más tarde conocido como App's Hungarian y la abominación posterior llamada System Hungarian después de que algunos tontos (es un término técnico) leyeron totalmente mal el documento original de Simonyi .

Desafortunadamente, el Sistema HN fue propagado por Petzold y otros para convertirse en el aborto más dominante que legítimamente se reconoce hoy en día.

Lea el excelente artículo de Joel sobre la intención de la notación húngara original de Apps y sea perdón por lo que se perdió en la prisa.

Si lo que tienes es el húngaro de la aplicación, probablemente quieras conservarlo después de leer tanto el artículo original de Charles Simonyi como el artículo de Joel.

¿Si ha aterrizado en una pila humeante de Sistema Húngaro?

¡Todas las apuestas están apagadas!

¡Menos mal! (dicho mientras se tapa la nariz) (-:

si se siente afortunado y solo quiere que el húngaro se vaya, aísle los prefijos húngaros que se usan e intente buscar y reemplazar en el archivo para reemplazarlos con nada , luego limpie y reconstruir Si el número de errores es pequeño, simplemente corríjalo. Si el número de errores es enorme, regrese y divídalo primero en clases lógicas (por dominio), luego cambie el nombre individualmente (el IDE ayudará)

Solía ??usarlo religiosamente en los días de VB6, pero paré cuando salió VB.NET porque eso es lo que decían las nuevas pautas de VB. Otros desarrolladores no lo hicieron. Entonces, tenemos un montón de código antiguo con él. Cuando hago mantenimiento en el código, elimino la notación de las funciones / métodos / sub que toco. No lo eliminaría todo de una vez a menos que tenga pruebas unitarias realmente buenas para todo y pueda ejecutarlas para demostrar que nada está roto.

¿Cuánto vas a romper haciendo esto? Esa es una pregunta importante que debes hacerte. Si hay muchas otras piezas de código que usan esa biblioteca, entonces podría estar creando trabajo para la gente (tal vez usted) realizando el ejercicio de cambio de nombre.

Lo pondría en la lista de cosas que hacer al refactorizar. Al menos, todo el mundo espera que rompas la biblioteca (temporalmente).

Dicho esto, me siento totalmente frustrado con métodos y variables mal nombrados, por lo que puedo relacionarme.

No haría un proyecto fuera de él. Usaría las herramientas de refactorización en VS (en realidad, usaría Resharper's, pero VS funciona bien) y arreglaría todas las variables en cualquier método que me pidieron modificar. O si tuviera que hacer cambios a mayor escala, refactorizaría los nombres de las variables en cualquier método que se me pidiera que entendiera .

Si tiene una necesidad legítima de eliminarlo y cambiarlo, usaría las herramientas de refactorización integradas o algo así como Resharper.

Sin embargo, estaría de acuerdo con Chris Conway en un cierto punto de vista y le preguntaría POR QUÉ, sí, es molesto, pero al mismo tiempo, muchas veces el " si no está roto, no soluciona es " ¡El método es realmente la mejor manera de hacerlo!

Solo cámbielo cuando lo use directamente. Y asegúrese de tener un banco de pruebas listo para aplicar para asegurarse de que todavía funciona.

Estoy de acuerdo en que la mejor manera de eliminar gradualmente la notación húngara es refactorizar el código a medida que lo modifica. El mayor beneficio de hacer este tipo de refactorización es que debería escribir pruebas unitarias alrededor del código que está modificando para tener una red de seguridad en lugar de cruzar los dedos y esperar no romper la funcionalidad existente. Una vez que tenga estas pruebas unitarias, puede cambiar el código al contenido de su corazón.

¡Diría que un problema mayor es que tienes una sola clase con 200 (!) métodos!

Si esta es una clase muy dependiente / muy cambiada, entonces podría valer la pena refactorizarla para que sea más útil.

En esto, Resharper es una necesidad absoluta (puede usar el material de refactorización incorporado, pero Resharper es mucho mejor).

Comience a encontrar un grupo de métodos relacionados, y luego refactorícelos en una clase cohesiva pequeña y agradable. Actualice para cumplir con sus últimos estándares de código.

Compilar & amp; ejecuta tu suite de prueba.

¿Tienes energía para más? Extraer otra clase.
Desgastado - no hay problema; vuelve y haz algo más mañana. En solo unos días habrás conquistado a la bestia.

Estoy de acuerdo con @Booji: hágalo manualmente, por rutina cuando ya esté visitando el código por alguna otra buena razón. Luego, eliminará los más comunes, y a quién le importa el resto.

Estaba pensando en hacer una pregunta similar, solo en mi caso, el código ofensivo es mío. Tengo el viejo hábito de usar '' el tipo malo '' de húngaro de mis días en FoxPro (que tenía un tipeo débil y un alcance inusual) & # 8212; un hábito que acabo de patear recientemente.

Es difícil & # 8212; significa aceptar un estilo inconsistente en su base de código. Hace solo una semana finalmente dije "atorníllelo" y comenzó un nombre de parámetro sin la letra "p". La disonancia cognitiva que sentí inicialmente ha dado paso a un sentimiento de libertad. El mundo no llegó a su fin.

La forma en que he estado abordando este problema es cambiando una variable a la vez a medida que las encuentro, luego realizo más cambios radicales cuando vuelves para hacer cambios más profundos. Si eres como yo, la diferente nomenclatura de tus variables te volverá loco de bat-shiat por un tiempo, pero lentamente te acostumbrarás. La clave es eliminarlo poco a poco hasta que tenga todo lo que necesita.

Alternativamente, puede deshacerse de sus variables por completo y simplemente hacer que cada función devuelva 42.

Me parece que el problema más grande es que la clase God Object de 200 métodos. Sugeriría que refactorizar solo para eliminar la notación húngara es una actividad de bajo valor y alto riesgo en sí misma. A menos que haya una gran cantidad de pruebas unitarias automatizadas alrededor de esa clase para darle cierta confianza en su refactorización, creo que debería dejarla bien y realmente sola.

Supongo que es poco probable que exista un conjunto de pruebas de este tipo, ya que un desarrollador que siga las prácticas TDD (naturalmente) habría evitado construir un objeto divino en primer lugar; sería muy difícil escribir pruebas exhaustivas para ello.

Sin embargo, eliminar el objeto dios y obtener una base de prueba unitaria es de mayor valor. Mi consejo sería buscar oportunidades para refactorizar la clase en sí, tal vez cuando se presente un requisito / cambio comercial adecuado que requiera un cambio en ese código (y, por lo tanto, con algunas pruebas de sistema y de regresión compradas y pagadas). Es posible que no pueda justificar el esfuerzo de refactorizar todo de una vez, pero puede hacerlo pieza por pieza a medida que se presente la oportunidad y probar los cambios. De esta forma, puede convertir lentamente el código de spaghetti en una base de código más limpia con pruebas unitarias completas, poco a poco.

Y puedes eliminar el húngaro a medida que avanzas, si quieres.

Realmente estoy haciendo lo mismo aquí para una extensión de aplicación. Mi enfoque ha sido utilizar las asignaciones de VIM para buscar prefijos de notación húngara específicos y luego eliminarlos y corregir las mayúsculas según corresponda.

Ejemplos (va en vimrc): 

"" Hungarian notation conversion helpers
"" get rid of str prefixes and fix caps e.g. strName -> name
map ,bs /\Wstr[A-Z]^Ml3x~
map ,bi /\Wint[A-Z]^Ml3x~
"" little more complex to clean up m_p type class variables
map ,bm /\Wm_p\?[A-Z]^M:.s/\(\W\)m_p\?/\1_/^M/\W_[A-Z]^Mll~
map ,bp /\Wp[A-Z]^Mlx~

Si vas a romper el código solo por refactorizar, consideraría seriamente dejarlo solo, especialmente, si vas a afectar a otras personas en tu equipo que pueden depender de ese código.

Si su equipo está de acuerdo con esta refactorización e invierte su tiempo en hacer esto (lo que puede ahorrarle tiempo en el futuro, si eso significa que el código es más legible / mantenible), use Visual Studio (o cualquier IDE que está usando) para ayudarlo a refactorizar el código.

Sin embargo, si un gran cambio como este no es un riesgo que su equipo / jefe está dispuesto a asumir, sugeriría un enfoque a medio camino poco ortodoxo. En lugar de refactorizar todo en un solo barrido, ¿por qué no refactorizar secciones de código (más específicamente, funciones) que deben tocarse durante el mantenimiento normal? Con el tiempo, esta refactorización lenta llevará el código a un estado más limpio, momento en el que puede finalizar el proceso de refactorización con un barrido final.

Me encanta la notación húngara. No entiendo por qué querrías deshacerte de él.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top