Il modo migliore per sbarazzarsi della notazione ungherese?

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

Domanda

Supponiamo che tu abbia ereditato una base di codice C # che utilizza una classe con 200 metodi statici per fornire funzionalità di base (come le ricerche nel database). Dei molti incubi in quella classe, c'è un uso abbondante della notazione ungherese (il tipo cattivo).

Rifattereresti i nomi delle variabili per rimuovere la notazione ungherese o li lasceresti soli?

Se scegli di modificare tutte le variabili per rimuovere la notazione ungherese, quale sarebbe il tuo metodo?

È stato utile?

Soluzione

Lascialo in pace. Ci sono usi migliori del tuo tempo.

Altri suggerimenti

Refactor - Trovo che la notazione ungherese su quella scala interferisca davvero con la naturale leggibilità del codice e l'esercizio è un buon modo per familiarizzare con ciò che c'è.

Tuttavia, se ci sono altri membri del team che conoscono la base di codice, avresti bisogno di un consenso sul refactoring e se una qualsiasi delle variabili è esposta al di fuori di un progetto, dovrai lasciarle in pace.

Fai clic destro sul nome della variabile, Refactor - > Rinomina.

Ci sono anche componenti aggiuntivi VS che fanno questo, ma il metodo integrato funziona bene per me.

Cosa dovrei fare? Supponendo che devo solo mantenere il codice e non riscriverlo in modo significativo? Lascialo da solo. E quando faccio aggiungo codice, seguo lo stile esistente, ovvero uso quella brutta notazione ungherese (sporca come mi fa sentire.)

Ma, ehi, se hai davvero un hankerin 'fer refactorin' , fai solo un po 'alla volta. Ogni volta che ci lavori trascorri dieci minuti a rinominare le variabili. Mettere in ordine le cose un po '. Dopo alcuni mesi potresti scoprire che è pulito come un fischio ....

Non dimenticare che esistono due tipi di notazione ungherese.

L'originale Charles Simonyi HN, in seguito noto come l'ungherese dell'App e l'abominio successivo chiamato System Hungarian dopo che un po 'di becca (è un termine tecnico) è stato completamente frainteso Articolo originale di Simonyi .

Sfortunatamente, il sistema HN è stato propagato da Petzold e altri per diventare l'aborto più dominante che è giustamente riconosciuto come oggi.

Leggi eccellente articolo di Joel sull'intento della Notazione ungherese originale di app ed essere scusa per quello che si è perso nella fretta.

Se quello che hai è l'app ungherese, probabilmente vorrai mantenerlo dopo aver letto sia l'articolo Charles Simonyi originale che l'articolo Joel.

Se sei atterrato in una pila fumante di System Hungarian?

Tutte le scommesse sono disattivate!

Accidenti! (disse tenendo il naso) (-:

se ti senti fortunato e vuoi solo che l'ungherese se ne vada, isola i prefissi ungheresi utilizzati e prova una ricerca e sostituisci nel file per sostituirli con niente , quindi fai una pulizia e ricostruire. Se il numero di errori è piccolo, correggilo. Se il numero di errori è enorme, torna indietro e suddividilo prima in classi logiche (per dominio), quindi rinomina individualmente (l'IDE aiuterà)

Lo usavo religiosamente nei giorni VB6, ma mi sono fermato quando è uscito VB.NET perché è quello che dicevano le nuove linee guida VB. Altri sviluppatori no. Quindi, abbiamo un sacco di vecchio codice con esso. Quando eseguo la manutenzione sul codice rimuovo la notazione dalle funzioni / metodi / sub tocco. Non rimuoverei tutto in una volta a meno che non abbia test unitari davvero buoni per tutto e possa eseguirli per provare che nulla è rotto.

Quanto hai intenzione di rompere facendo questo? Questa è una domanda importante da porsi. Se ci sono molti altri pezzi di codice che usano quella libreria, allora potresti semplicemente creare lavoro per la gente (forse tu) attraverso l'esercizio di ridenominazione.

Lo metterei nella lista delle cose da fare durante il refactoring. Almeno allora tutti si aspettano che tu rompa la libreria (temporaneamente).

Detto questo, sono totalmente frustrato dai metodi e dalle variabili mal nominati, quindi posso relazionarmi.

Non ne farei un progetto. Userei gli strumenti di refactoring in VS (in realtà, userei Resharper, ma VS funziona alla perfezione) e sistemerei tutte le variabili in qualsiasi metodo che sono stato chiamato a modificare. O se dovessi apportare modifiche su larga scala, rifarrei i nomi delle variabili in qualsiasi metodo mi è stato chiesto di comprendere .

Se hai un legittimo bisogno di rimuoverlo e modificarlo, utilizzerei gli strumenti di refactoring integrati o qualcosa come Resharper.

Tuttavia, sarei d'accordo con Chris Conway su un certo punto di vista e ti chiederò PERCHÉ, sì, è fastidioso, ma allo stesso tempo, il più delle volte se non è rotto non risolto it " Il metodo è davvero il modo migliore per andare!

Modificalo solo quando lo usi direttamente. E assicurati di avere un banco di prova pronto da applicare per assicurarti che funzioni ancora.

Sono d'accordo sul fatto che il modo migliore per eliminare gradualmente la notazione ungherese è di refactoring il codice mentre lo modifichi. Il più grande vantaggio di questo tipo di refactoring è che dovresti scrivere unit test attorno al codice che stai modificando in modo da avere una rete di sicurezza invece di incrociare le dita e sperare di non rompere le funzionalità esistenti. Una volta che hai messo in atto questi test unitari, sei libero di modificare il codice in base al tuo cuore.

Direi che un problema maggiore è che hai una singola classe con 200 (!) metodi!

Se questa è una classe molto dipendente / molto cambiata, potrebbe valere la pena rifattorizzare per renderla più utilizzabile.

In questo, Resharper è un must assoluto (potresti usare le cose di refactoring integrate, ma Resharper è molto meglio).

Inizia a trovare un gruppo di metodi correlati, quindi rifletti questi in una piccola classe coerente. Aggiornamento per conformarsi ai più recenti standard di codice.

Compila e amp; esegui la tua suite di test.

Hai energia per di più? Estrai un'altra classe.
Consumato - nessun problema; torna e fai un po 'di più domani. In pochi giorni avrai conquistato la bestia.

Sono d'accordo con @Booji - fallo manualmente, su base per routine quando stai già visitando il codice per qualche altro motivo. Quindi, toglierai i più comuni e chi se ne frega del resto.

Stavo pensando di fare una domanda simile, solo nel mio caso, il codice offensivo è mio. Ho una vecchissima abitudine di usare "il tipo cattivo" di ungherese dai miei giorni FoxPro (che aveva una digitazione debole e una definizione insolita) & # 8212; un'abitudine che ho calciato solo di recente.

È difficile & # 8212; significa accettare uno stile incoerente nella tua base di codice. Solo una settimana fa ho finalmente detto "avvitalo" e ha iniziato un nome di parametro senza la lettera "p". La dissonanza cognitiva che ho sentito inizialmente ha lasciato il posto a un sentimento di libertà. Il mondo non è finito.

Il modo in cui ho affrontato questo problema sta cambiando una variabile alla volta quando le incontro, quindi eseguo ulteriori cambiamenti radicali quando torni a fare modifiche più approfondite. Se sei come me, la diversa nomenclatura delle tue variabili ti farà impazzire per un po ', ma ti abituerai lentamente. La chiave è di eliminarla un po 'alla volta fino a quando non hai tutto ciò che deve essere.

In alternativa, è possibile eliminare completamente le variabili e fare in modo che ogni funzione restituisca 42.

Mi sembra che il problema maggiore sia che la classe 200a God Object . Suggerirei che il refactoring solo per rimuovere la notazione ungherese è un'attività di basso valore e ad alto rischio in sé. A meno che non ci sia un copioso set di unit test automatici intorno a quella classe per darti un po 'di fiducia nel tuo refactoring, penso che dovresti lasciarlo bene e davvero solo.

Immagino sia improbabile che esista un tale insieme di test, perché uno sviluppatore che segue le pratiche TDD avrebbe (si spera) naturalmente evitato di costruire un oggetto divino in primo luogo - sarebbe molto difficile scrivere test completi per.

Tuttavia, eliminare l'oggetto god e mettere in piedi una base di test unitari ha un valore più alto. Il mio consiglio sarebbe quello di cercare opportunità per il refactoring della classe stessa - forse quando arriva un adeguato requisito / cambiamento aziendale che richiede una modifica a quel codice (e quindi si spera che venga fornito con alcuni test di regressione di sistema acquistati e pagati). Potresti non essere in grado di giustificare lo sforzo di refactoring del tutto in una volta, ma puoi farlo pezzo per pezzo man mano che l'occasione si presenta e testare i cambiamenti. In questo modo puoi convertire lentamente il codice spaghetti in una base di codice più pulita con test unitari completi, bit per bit.

E puoi eliminare l'ungherese come preferisci, se vuoi.

In realtà sto facendo la stessa cosa qui per un'estensione dell'applicazione. Il mio approccio è stato quello di utilizzare i mapping VIM per cercare prefissi di notazione ungheresi specifici e quindi eliminarli e correggere le maiuscole nel modo appropriato.

Esempi (va in 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~

Se infrangerai il codice solo per motivi di refactoring, prenderei seriamente in considerazione di lasciarmi solo, specialmente se intendi influenzare altre persone nella tua squadra che potrebbero dipendere da quel codice.

Se il tuo team è d'accordo con questo refactoring e investi il ??tuo tempo nel fare ciò (che potrebbe essere un risparmio di tempo in futuro, se significa che il codice è più leggibile / gestibile), usa Visual Studio (o qualunque IDE stai utilizzando) per aiutarti a refactificare il codice.

Tuttavia, se un grande cambiamento come questo non è un rischio che il tuo team / capo è disposto a correre, suggerirei un approccio un po 'poco ortodosso, a metà strada. Invece di eseguire tutto il refactoring in un'unica scansione, perché non refactoring sezioni di codice (più specificamente, funzioni) che devono essere toccate durante la normale manutenzione? Nel tempo, questo refactoring lento porterà il codice a uno stato più pulito, a quel punto puoi terminare il processo di refactoring con uno sweep finale.

Adoro la notazione ungherese. Non capisco perché vorresti sbarazzartene.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top