Funzionalità retrò nuove lingue adattate C # (o qualsiasi altra lingua)
Domanda
Quando si lavora con la mia base di codice .Net 2.0 ReSharper consiglia continuamente di applicare le ultime funzionalità del linguaggio c # 3.0, in particolare; convertire le proprietà semplici in proprietà di auto-implementazione o dichiarando variabili locali come var. Tra gli altri.
Quando arriva una nuova funzione di lingua, torni indietro e la applichi religiosamente attraverso la tua base di codice esistente o lasci il codice come scritto originariamente, accettando che se il nuovo codice viene scritto usando le nuove funzionalità di lingua, ci saranno incoerenze tra il tuo codice?
Soluzione
Se non è rotto, non aggiustarlo. Naturalmente, se hai fiducia nei tuoi test unitari, puoi fare un vortice, ma non dovresti davvero cambiare casualmente il codice " solo perché " ;.
Ovviamente - in alcuni casi, la semplificazione del codice è un motivo valido per apportare una modifica - ma anche qualcosa di innocente come il passaggio a una proprietà implementata automaticamente potrebbe rompere il codice che fa ipotesi e utilizza la riflessione per aggiornare direttamente i campi. Oppure potrebbe interrompere la serializzazione.
Passa a " var " può effettivamente darti un tipo diverso (più specifico), che potrebbe causare la selezione di un sovraccarico del metodo diverso, ecc.
Quindi di nuovo; dipende dalla tua fiducia nei test unitari.
Altre considerazioni:
- il resto del team comprende ancora la nuova sintassi?
- il tuo progetto deve supportare C # 2.0 (ad esempio, alcuni progetti open source potrebbero voler mantenere la compatibilità con C # 2.0).
Se nessuno di questi è un problema, dovresti essere OK per usare le nuove funzionalità nel nuovo codice ... basta essere un poco cauto prima di colpire " aggiorna tutto " sul vecchio codice ...
Ecco un banale esempio di " var " come cambiamento decisivo:
static void Main() {
using (TextReader reader = File.OpenText("foo.bar")) { // [HERE]
Write(reader);
}
}
static void Write(TextReader reader) {
Console.Write(reader.ReadToEnd());
}
static void Write(StreamReader reader) {
throw new NotImplementedException();
}
Ora passa a var reader
sulla riga contrassegnata [HERE]
...
Altri suggerimenti
Manterrei semplicemente il codice man mano che procederò. Alla fine gran parte dell'app sarà stata ripulita o adattata alle nuove funzionalità e miglioramenti. Non cambiare qualcosa per il gusto di cambiarlo. Se non si ottengono miglioramenti delle prestazioni o della stabilità, non è necessario perdere tempo ad aggiornare il codice.
C # 3 basato su C # 2 ed entrambi sono abbastanza compatibili. Quindi ogni aggiornamento dovrebbe essere riflettuto su.
Lo lascio fino a quando non cambio quella linea (o spesso solo le linee vicino ad essa). Quindi aggiorno. (A volte aggiornerò l'intera classe o il file, una volta che cambierò uno di essi)
Lascio che sia. Oltre al fatto che sarebbe un sacco di lavoro, c'è anche il problema è che il codice è davvero lo stesso o ci sono effetti collaterali della nuova funzionalità.
Nel caso specifico di var, il compilatore inserisce comunque il tipo corretto in fase di compilazione, quindi non c'è davvero alcun vantaggio.
EDIT: In realtà mi sbaglio sul var non rompere le cose, quindi sì, il mio consiglio originale è valido. Se non è rotto ...