2009-03-30 18 views
5

Un numero di funzionalità sono state introdotte in C# 3.0 che mi ha reso difficile, come inizializzatori di oggetti, metodi di estensione e variabili implicite tipizzate. Ora in C# 4.0 con cose come la parola chiave dinamica mi sto preoccupando ancora di più.Come gestisci le nuove funzionalità di C# in modo che non conducano a codice scritto male?

So che ciascuna di queste caratteristiche PUÒ essere utilizzato in modo appropriato MA a mio avviso, che rendono più facile per gli sviluppatori di prendere decisioni di codifica cattive e quindi scrivere il codice di peggio. Mi sembra che Microsoft stia cercando di conquistare quote di mercato rendendo la codifica semplice e poco impegnativa. Personalmente preferisco un linguaggio rigoroso e pone più richieste ai miei standard di codifica e mi costringe a strutturare le cose in modo OOP.

Ecco alcuni esempi delle mie preoccupazioni per le caratteristiche di cui sopra:

costruttori degli oggetti possono fare importanti logica che non è esposto al consumatore. Questo è nel controllo dello sviluppatore di oggetti. Gli inizializzatori degli oggetti tolgono questo controllo e consentono al consumatore di prendere le decisioni su quali campi inizializzare.

EDIT: Non avevo apprezzato il fatto che si potesse mescolare il costruttore e l'inizializzatore (il mio male) ma questo comincia a sembrare disordinato per la mia mente e quindi non sono ancora convinto che sia un passo avanti.

Consentire agli sviluppatori di estendere i tipi predefiniti utilizzando i metodi di estensione consente a tutti di iniziare a aggiungere i loro metodi preferiti per animali domestici alla classe stringa, che può finire con una sconcertante serie di opzioni o richiede un maggiore controllo degli standard di codifica in estirpare questi

Consentire variabili implicite tipizzate consente una programmazione rapida e sporca, piuttosto che approcci OOP appropriati, che possono rapidamente diventare un disordine ingovernabile di vars su tutta l'applicazione.

Le mie preoccupazioni sono giustificate?

+0

RobW: è necessario riformulare la domanda. "Microsoft è giusto" è un argomento polemico, mentre "Come gestisci le nuove funzionalità di C# in modo che non conducano a un codice scritto male" non è – Brann

+0

OK, darai un risultato! Non cercavo di essere polemico, ed è per questo che ho fornito esempi del mio punto di vista, sono intuibile in ciò che pensano gli altri sviluppatori. –

+0

È anche una domanda di "discussione" senza una risposta definitiva (solo opinioni) e quindi la wiki della comunità sarebbe appropriata. –

risposta

5

Gli inizializzatori di oggetti consentono semplicemente al client di impostare le proprietà immediatamente dopo la costruzione, nessun controllo viene abbandonato poiché il chiamante deve comunque assicurarsi che tutti gli argomenti del costruttore siano soddisfatti.

Personalmente mi sento aggiungono molto poco:

Person p1 = new Person("Fred"); 
p1.Age = 30; 
p1.Height = 123; 

Person p2 = new Person("Fred") 
{ 
    Age = 30; 
    Height = 123; 
}; 

Conosco un sacco di persone non amano la parola 'var'.Posso capire perché in quanto è un abuso che invita apertamente, ma non mi dispiace che fornisce il tipo è assolutamente ovvio:

var p1 = new Person("Fred"); 
Person p2 = GetPerson(); 

Nella seconda riga sopra, il tipo non è evidente, nonostante il nome del metodo. Vorrei usare il tipo in questo caso.

Metodi di estensione - Vorrei usarlo con parsimonia ma sono molto utili per estendere i tipi .NET con metodi di convenienza, specialmente IEnumerable, ICollection e String. String.IsNullOrEmpty() come metodo di estensione è molto bello, in quanto può essere chiamato su riferimenti null.

Non penso che sia necessario preoccuparsi, i buoni sviluppatori useranno sempre i loro strumenti con rispetto e gli sviluppatori cattivi troveranno sempre dei modi per sbagliare i loro strumenti: limitare il set di strumenti non risolverà questo problema.

+0

Grazie per il puntatore sulla combinazione di inizializzatore costruttore, domanda aggiornata in base a questo. –

+0

Nessun problema. Credo che gli inizializzatori dell'oggetto siano stati aggiunti per i tipi anonimi in cui non è possibile specificare un costruttore perché il tipo non ha nome! Ho idea del perché i lang del C++ continuino a insistere su cstr con nome == al nome della classe: un metodo di inizializzazione chiamato Initialize(), come Ruby, sarebbe meglio IMO. –

+0

In realtà, si sbaglia molto sugli inizializzatori dell'oggetto. C'è una grande differenza: nel tuo primo esempio di stile "vecchio", ogni incarico verrà trattato come un'operazione atomica, che potenzialmente porta a una finestra temporale che lo stato dell'oggetto non è coerente.La sintassi "New" valuterà insieme – ArielBH

0

Gli inizializzatori di oggetti sono solo sintassi di fantasia. Non c'è nulla che lo sviluppatore possa fare con loro che non potrebbe già fare prima - tuttavia ti fanno risparmiare poche righe di codice.

Se con "estendi tipi incorporati" si intendono i metodi di estensione, anche in questo caso non è una novità, ma solo una sintassi migliore. I metodi sono metodi statici che appaiono come se fossero membri. Le classi costruite rimangono intatte.

Per Linq sono necessarie variabili implicite tipizzate. Li uso anche con generici che hanno molti parametri di tipo. Ma sono d'accordo che non mi piacerebbe vederli usati esclusivamente.

Ovviamente tutte le funzionalità possono essere sfruttate male, ma penso che queste nuove funzionalità ti consentano di scrivere codice che è più facile da leggere.

2

È possibile limitare le funzionalità di C# 3.0 che gli sviluppatori possono utilizzare scrivendo le restrizioni negli standard di codifica. Quindi, quando il codice viene rivisto prima del check-in, qualsiasi codice che viola queste regole dovrebbe essere individuato e il check-in rifiutato. Uno di questi casi potrebbe essere un metodo di estensione.

Ovviamente, gli sviluppatori vorranno utilizzare le nuove funzionalità: tutti gli sviluppatori. Tuttavia, se hai buoni motivi ben documentati per cui non dovrebbero essere usati, i buoni sviluppatori li seguiranno. Dovresti anche essere aperto a rivedere queste regole quando nuove informazioni verranno alla luce.

Con VS 2008 è possibile specificare quale versione di .NET si desidera targetizzare (fare clic con il pulsante destro del mouse sulla soluzione e selezionare Proprietà> Applicazione). Se ti limiti a .NET 2.0, non otterrai nessuna delle nuove funzionalità in .NET 3.5. Ovviamente questo non aiuta se si desidera utilizzare alcune delle funzionalità.

Tuttavia, penso che le tue paure oltre vars non siano giustificate. C# è ancora fortemente digitato come sempre. Dichiarare qualcosa come var dice semplicemente al compilatore di scegliere il tipo migliore per questa variabile. La variabile non può cambiare tipo è sempre un int o Person o qualsiasi altra cosa. Personalmente seguo le stesse regole di Paul Ruane; se il tipo è deselezionato dalla sintassi, utilizzare uno var; se non nominare il tipo esplicitamente.

+0

Non sarei interessato a lavorare per una società che introdurrebbe tabù su nuove funzionalità poiché equivale a lavorare con una vecchia tecnologia e non estenderete le vostre competenze ed esperienze. – User

+0

Anche se in linea di principio sono solidale, nel mondo degli affari, non direi che C# 2.0 (ad esempio) è esattamente una "vecchia tecnologia". Se stessero scrivendo un nuovo software in COBOL, potrei essere d'accordo. – mquander

+0

Troll @SO: tutto ciò che sottolineo è che puoi limitare ciò che gli sviluppatori possono fare. Ad esempio, potresti non essere in grado di installare .NET 3.5 sul server. – ChrisF

0

Un grande fattore attenuante su var è che non può mai spostarsi tra gli ambiti. Non può essere un tipo di ritorno o un tipo di parametro. Questo lo rende molto più sicuro nella mia mente, dato che è sempre scritto a macchina e sempre con i dettagli di implementazione di un metodo.

+0

Stai pensando ai tipi anonimi, var fa solo la digitazione implicita. –

+0

"le variabili dichiarate nell'ambito del metodo possono avere un tipo implicito var" http://msdn.microsoft.com/en-us/library/bb383973.aspx. var può essere solo variabili locali del metodo, non membri di livello classe o tipo di ritorno o tipo di parametro. –

0

Sono state introdotte nuove funzionalità perché Microsoft ha compreso che sono assolutamente necessarie per l'implementazione di nuove funzionalità linguistiche. Come LINQ, per esempio. Quindi è possibile utilizzare la stessa strategia: 1) conoscere queste funzioni, 2) non utilizzare fino a quando non si trova assolutamente necessario per voi.

Se capisci davvero quelle caratteristiche, scommetto che ti sentiresti necessario molto presto. :)

+0

Mi rendo perfettamente conto che molte delle novità in C# 3 sono state guidate da LINQ, come ho detto, so che ogni funzionalità ha i suoi usi corretti, il mio punto è che sommati tutti questi cambiamenti stanno avendo un effetto negativo sulla lingua. –

+0

IMHO, se guardi al numero di programmi scritti in qualsiasi lingua, troverai tutti i diversi tipi di abuso. :) Certo, alcune lingue sono più facili da abusare. Come Perl. Sono un appassionato di architettura, quindi penso che ogni sviluppatore dovrebbe pensarci prima. – XOR

2

Ho visto la tua posizione espressa in questo modo:

costruire un ambiente di sviluppo che qualsiasi sciocco può utilizzare e ciò che si ottiene è molti sciocchi in via di sviluppo.

Questo è molto vero, ma il resto di noi sembra buono al contrario. Lo considero una cosa buona.Uno dei post più divertenti che abbia mai visto ha rilevato che

VB non deve essere sottostimato. È uno strumento estremamente potente per che mantiene gli idioti fuori dal gruppo di discussione [C++].

Più seriamente, se uno strumento è pericoloso o meno dipende dalla saggezza del possessore. l'unico modo per prevenire la follia è impedire l'azione. foreach sembra innocuo ma non è possibile rimuovere gli elementi mentre si itera una raccolta perché la rimozione di un elemento invalida l'iteratore. Finisci per scaricarli a favore di un ciclo classico.

1

Penso che l'unico problema veramente giustificato nel tuo gruppo sia l'uso eccessivo dei metodi di estensione. Quando le funzionalità importanti sono accessibili solo tramite i metodi di estensione, a volte è difficile per tutti in un gruppo scoprire e utilizzare tale funzionalità.

Preoccuparsi per gli inizializzatori di oggetti e la parola chiave "var" sembra molto nitpicky. Entrambe sono sintassi semplici e prevedibili che possono essere utilizzate per rendere il codice più leggibile e non mi è chiaro come le vedi "abusate".

Vi suggerisco di affrontare problemi come questo attraverso standard di codifica scritti e concordati. Se nessuno riesce a tirar fuori buone ragioni per usare le nuove funzionalità linguistiche, non c'è bisogno di usarle, dopotutto.

-3

Le mie preoccupazioni sono giustificate?

No. Questa è stata un'altra edizione di risposte semplici a domande semplici.

+0

Vota me se vuoi, so che è stata una risposta irriverente. Ma la domanda era se le sue preoccupazioni fossero sostenute con adeguata giustificazione, e secondo la mia onesta opinione, no, non lo erano. Voglio dire, perché lasciare fuori il classico, "le proprietà sono solo zucchero sintattico == codice errato" denuncia? –

0

Almeno con "var" e intializzatori non sei veramente in grado di fare nulla di nuovo, è solo un nuovo modo di scrivere le cose. Sebbene assomigli agli inizializzatori degli oggetti, compila un IL leggermente diverso.

Un angolo che mi fa venire in mente i metodi di estensione è che è possibile inserirli in un'interfaccia. Ciò significa che una classe può ereditare codice concreto implementando un'interfaccia. E dal momento che una classe può implementare più interfacce che significa, in una sorta di rotatoria, che C# ora ha qualcosa come l'ereditarietà multipla. Quindi questa è una nuova funzionalità che dovrebbe essere gestita con cura.

Problemi correlati