C # 6: Devo refactoring il mio codice usando Resharper per le nuove funzionalità? [chiuso]

Question

C # 6: Devo refactoring il mio codice usando Resharper per le nuove funzionalità? [chiuso]

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

1

C # 6 è qui da un po 'di tempo e porta con sé dello zucchero sintattico che Resharper è abbastanza gentile da evidenziare e consigliare di "migrare a". Devo applicare queste correzioni automaticamente all'intero code base e confermare? Anche se questa domanda può essere applicata a qualsiasi nuova funzione nella lingua, le principali che sto considerando di applicare sono:

Utilizza l'interpolazione della stringa anziché string.ToString
Cambia proprietà da ottenere {...} in espressione body (= >)
Utilizza propagazione null
Rendi la proprietà automatica solo

Che cosa succede se si tratta di centinaia di modifiche? E se fosse migliaia?

c# refactoring resharper

posta ytoledano 28.08.2015 - 23:28

fonte

3 risposte

Leggi altre domande sui tag c# refactoring resharper

Utilizzo di connessioni locali anziché globali Registrazione dei nomi di funzioni su sistemi con poche risorse (di memoria e di spazio)

score 3 · Answer 1

Se stavi parlando di refactoring manuale per portare il tuo codice su "C # 6.0 standard", voterei pesantemente contro il refactoring di parti del tuo codice in aree in cui non stai attualmente lavorando. Ciò comporterebbe solo un beneficio minimo per un certo rischio di rompere le cose involontariamente.

Tuttavia, stai parlando di una migrazione automatizzata. In tale situazione, puoi considerare di consentire al tuo strumento di refactoring di applicare i passaggi se prima controlli le seguenti condizioni preliminari:

lo sforzo manuale è veramente piccolo
tutti nel tuo team conoscono le nuove funzionalità linguistiche, almeno nella misura in cui lui / lei può leggerle e comprenderle
ti fidi del tuo strumento di refactoring che non si rompa nulla durante l'applicazione di tali patch (e anche allora, dovresti avere abbastanza test automatici per controllarlo da solo)
il risultato del refactoring automatico è molto più leggibile e non è necessario modificare manualmente il risultato per ristabilire la leggibilità.
le nuove funzionalità che vuoi utilizzare da C # 6.0 non impongono un aggiornamento indesiderato a una nuova versione di .NET framework che potresti non essere ancora pronta per usare

score 1 · Answer 2

Dipende.

Non tutte le funzionalità / usi c # 6 sono disponibili nelle versioni .NET inferiori (vedi link ). Se i tuoi consumatori non riescono a passare alle ultime e migliori librerie, non aggiornare.

Il tuo team conosce le nuove funzionalità? Altrimenti, dovresti fare un po 'di allenamento prima di scaricare tutto nel controllo del codice sorgente.

Dopo ciò dipende se la tua squadra pensa che lo zucchero sintattico aggiunga alla leggibilità. Probabilmente cambierei alcune classi e farò confrontare la tua squadra, errando nei confronti della nuova sintassi poiché le persone troveranno nuove cose meno leggibili per impostazione predefinita.

score 0 · Answer 3

No. Non dovresti. Almeno, sicuramente non avrei colpito il pulsante "Correggi tutte le cose".

Adoro Resharper, ma non sempre prende le decisioni migliori. Se lo facesse, non ci avrebbe dato la possibilità di ignorare avvisi / suggerimenti con un commento. Il fatto è che a volte questi refactoring portano a un codice meno leggibile e, in alcuni casi, può rompere le cose. (Ho avuto alcuni problemi con il codice di interoperabilità COM e i suggerimenti di ReSharper in passato.)

Quindi, se stai per colpire quel grosso pulsante rosso, è meglio avere una buona serie di test sul posto.

Questo non significa che non dovresti farlo affatto, ma personalmente mi prenderei il tempo per controllare e applicare personalmente i refactoring. Forse mentre lavori su un file, o forse impieghi qualche ora per ripulire l'intero progetto. In entrambi i casi, una persona deve rivedere questi cambiamenti. Non lasciare che la macchina prenda decisioni per te. Se ho imparato qualcosa come programmatore, è che la macchina non ha sempre ragione e tutto il codice ha dei bug. Anche il codice da parte delle persone meravigliose di JetBrains.

Correlati: Visual Studio Rot the Mind?