Qualche settimana fa ho iniziato a scrivere un post in cui volevo parlare dell'uso delle guidelines e delle convenzioni di naming e avevo iniziato a scrivere quanto segue.
Quando mi occupo di conversione/integrazione di codice scritto da altri mi convinco che il modo in cui si scrive il codice è importante e mi accorgo di quante filosofia nella scrittra del codice esistono; filosofie dettate da pigrizia o da personali preferenze di bellezza visiva. Ogni linguaggio ha suoi decaloghi di scrittura del codice... usiamoli! ...almeno la guideline sul naming, Naming Guidelines. L'uso corretto del naming spiega un pezzo di codice più di quanto si possa pensare!
Leggere codice di altri non sempre è facile... leggere codice di altri che non rispetta le guidelines di naming potrebbe essere un'impresa. Scrivere seguendo le guidelines credo sia sinonimo di professionalità e rispetto per gli altri che toccheranno il mio codice.
Il post non venne mai pubblicato perchè non ebbi tempo di rileggerlo e lo feci cadere in coda. Sto riprendendo il post in seguito ad alcuni pensieri di questi giorni nel vedere lavorare sviluppatori entusiasti sbronzi dei nuovi arrivi nella rosa degli statement di c#: lambda expression, LINQ e metodi estesi... un'interessante guazzabuglio di stili e metodi che a volte vanno ad sovrapporsi nelle funzionalità.
Esempio per estrarre i numeri pari da un array di interi ho due modi. Usare LINQ
var numeriPari = from s in numeriInteri where s % 2 == 0 select s;
oppure usare esplicitamente Lambda Expression+Extended Methods delle collezioni/array
var numeriPari = numeriInteri.Where(s => s % 2 == 0);
E' la stessa cosa? Si. In realtà le funzionalità LINQ e Lambda Expression+Extended Methods non sono completamente sovrapposti ma ho nottato che a volte la scelta dello sviluppatore entusiasta non è dettata da un ragionato motivo o da una reale esigenza ma in base all'estro e al sentimento del momento. Credo che una buona regola sia scegliere una strada e seguirla. Ad esempio quella che tendenzialmente mi piacerà adottare sarà: usare sempre LINQ (a mio avviso più leggibile) e dove non possibile arrivare allo scopo usare Lambda Expression+Extended Methods. Credo che in questo modo il codice diventi meno variopinto/caotico/articolato anche agli occhi di nuovi partecipanti al progetto.
Voglliamo parlare dell'uso casuale di var? var nasce per esigenze precise legate a LINQ e espressioni lamba e la creazione di tipi on fly. Se il tipo è noto, perchè usare var? Solo per scrivere meno codice?
oO0(spero di non essere all'alba di un neo-impressionismo sulla scia degli entusiasti programatori C che non mandavano a capo il codice per dar sfoggio della loro bravura)
posted @ martedì 22 luglio 2008 12:58