Gli ultimi post di Edit
Linee guida nella scrittura di codice #11: I tipi nidificati
Venerdì 23 Novembre 2007 - 10:55
di Gianni Malanga

I tipi nidificati sono tipi definiti come membri di altri tipi (dichiaranti) che dovrebbero essere utilizzati solo quando strettamente necessario e comunque solo in quei casi in cui sia ben chiara la relazione tra i due tipi (dichiarante e nidificato).
Ecco un esempio di tipo nidificato:
public class Book
{
private class Price
{
Price() { }
}
}
Solitamente i tipi nidificati vengono utilizzati, o dovrebbero essere utilizzati, quando il tipo dichiarante ha la necessità di creare istanze del tipo nidificato e comunque il tipo nidificato non dovrebbe essere esposto attraverso membri pubblici.
Continua a leggere Linee guida nella scrittura di codice #11: I tipi nidificati
Categoria: Microsoft Dev | Permalink | Commenta
Linee guida nella scrittura di codice #10: Le eccezioni
Martedì 20 Novembre 2007 - 11:02
di Gianni Malanga

Generalmente un’eccezione viene generata quando un membro non riesce a portare a termine il compito per il quale è stato creato. Se ad esempio il metodo Open() dell’oggetto Connection non riesce a connettersi al database, genererà una eccezione in quanto non è riuscito a svolgere il suo compito che è quello di aprire una connessione con il DBMS. Naturalmente anche noi possiamo non solo gestire ma anche generare delle eccezioni.
In caso di errore, utilizzare sempre le eccezioni per comunicare l’accaduto e mai valori di ritorno quali codici di errore o messaggi predefiniti. Questo perché altrimenti si verrebbe a creare una situazione di ambiguità con conseguente perdita di standardizzazione.
Valutare di volta in volta l’opportunità di utilizzare il metodo System.Environment.FailFast(System.String) per terminare il processo attivo in tutti quei casi in cui il verificarsi di una eccezione comporta un pericolo nella prosecuzione dell’esecuzione perchè magari ci si potrebbe trovare con dati non validi o peggio potrebbero verificarsi perdite di dati. Questo metodo è disponibile a partire dalla versione 2.0 del .NET Framework.
Continua a leggere Linee guida nella scrittura di codice #10: Le eccezioni
Categoria: Microsoft Dev | Permalink | Commenta
Linee guida nella scrittura di codice #09: I campi
Martedì 13 Novembre 2007 - 09:25
di Gianni Malanga

I campi, come tutti sappiamo, sono i dati che appartengono ad un oggetto. In linea generale e soprattutto nel caso dei campi non statici, quindi d’istanza, questi non devono mai essere esposti direttamente allo sviluppatore come campi pubblici ma devono essere esposti tramite una proprietà pubblica che ne può controllare e gestire i valori assegnati.
Quindi i campi non dovrebbero mai essere definiti public o protected ma sempre private ed esposti tramite proprietà public. Nel caso specifico di campi che devono contenere dei valori costanti prestabiliti e che quindi non potranno mai essere modificati, definirli come costanti. È il caso ad esempio dei valori matematici quali P greco o E (costante di Eulero) di cui infatti si hanno delle costanti statiche nella classe del framework Math.
I valori dei campi costanti (definiti con const) vengono inseriti direttamente nel codice prodotto dal compilatore e quindi non possono in alcun modo essere modificati a runtime.
Continua a leggere Linee guida nella scrittura di codice #09: I campi
Categoria: Microsoft Dev | Permalink | Commenta
Linee guida nella scrittura di codice #08: Gli eventi
Giovedì 8 Novembre 2007 - 09:32
di Gianni Malanga

Gli eventi sono un sistema per mandare in esecuzione codice nel momento in cui viene eseguita una specifica azione e questo codice può essere eseguito prima o dopo l’azione. Il codice dell’evento viene eseguito tramite un delegato che è associato al metodo da eseguire nel momento in cui l’evento viene generato. La firma del metodo che gestisce l’evento oltre naturalmente ad essere uguale a quella del delegato a cui è associato, deve seguire le seguenti convenzioni:
- Il tipo di ritorno del metodo è void
- Il primo parametro deve essere un Object denominato sender e che corrisponde all’oggetto che ha generato l’evento
- Il secondo parametro denominato e deve essere di tipo EventArgs o comunque deve essere una classe derivata da EventArgs. Questo parametro conterrà i dati relativi all’evento generato
- Il metodo deve accettare soltanto i due parametri suddetti
Per gli eventi utilizzare sempre il verbo “generare” al posto del verbo “attivare” o di altri simili.
Possibilmente utilizzare System.EventHandler<T> per il gestore d’evento piuttosto che crearne uno manualmente. Naturalmente questa linea guida può essere seguita solo se si sta sviluppando in una delle versioni del .NET Framework che supportano i generics.
Continua a leggere Linee guida nella scrittura di codice #08: Gli eventi
Categoria: Microsoft Dev | Permalink | Commenta
Linee guida nella scrittura di codice #07: Proprietà o Metodo?
Martedì 6 Novembre 2007 - 09:06
di Gianni Malanga

Per scegliere quando è opportuno utilizzare una proprietà al posto di un metodo o viceversa si deve considerare che i metodi rappresentano delle azioni mentre le proprietà rappresentano dei valori o degli attributi. Le proprietà non dovrebbero quindi essere complesse nella loro implementazione e non dovrebbero modificare dei dati ma solo restituire valori.
L’utilizzo classico di una proprietà è quello di permettere la modifica del valore di un campo privato e la verifica preventiva del valore assegnato:
private string _name = "";
public string Name
{
get { return _name; }
set
{
if( value != null && value.Length <= 100)
{
_name = value;
}
else
{
throw new ApplicationException("Max length for Name is 100 characters");
}
}
}
Continua a leggere Linee guida nella scrittura di codice #07: Proprietà o Metodo?
Categoria: Microsoft Dev | Permalink | Commenta
Linee guida nella scrittura di codice #06: L’Overload
Venerdì 2 Novembre 2007 - 08:39
di Gianni Malanga

Quando si decide di mettere in overload un membro, tutti i membri in overload dovrebbero fornire variazioni della stessa funzionalità, ad esempio due membri WriteToLog in overload dovrebbero entrambi scrivere sempre su file e non invece uno su file e l’altro su DB (o viceversa).
È buona norma fornire overload che accettano un numero di parametri via via crescente per fornire un overload “semplificato” a fronte di altri overload più “complessi”. Ad esempio, la classe File espone il metodo Open che nella sua forma più semplice accetta solo il percorso su disco del file da aprire e un metodo di apertura, mentre nelle sue forme più evolute accetta ulteriori e più specifici parametri.
Nel caso di overload a cascata come citato precedentemente, è preferibile che gli overload più semplici chiamino gli overload più complessi e non implementino autonomamente la funzionalità richiesta in quanto in questo modo si duplicherebbe codice inutilmente.
Continua a leggere Linee guida nella scrittura di codice #06: L’Overload
Categoria: Microsoft Dev | Permalink | Commenta
Linee guida nella scrittura di codice #05: Gli Enum
Lunedì 29 Ottobre 2007 - 09:08
di Gianni Malanga

Gli enum sono insiemi di valori costanti utilizzati per rendere il codice più leggibile ed evitare l’uso di valori fissi nel codice oppure di variabili costanti. Vi sono due tipi di enum, quelli semplici, i cui valori possono essere utilizzati solo singolarmente e non in combinazione tra loro, e quelli di tipo Flag che invece possono essere messi in relazione tra loro attraverso operatori booleani.
È buona norma utilizzare sempre gli enumeratori per tipizzare fortemente parametri, proprietà e valori di ritorno dei membri che rappresentino insiemi di valori. A tal scopo è preferibile usare gli enum al posto delle costanti statiche. Ad esempio è sconsigliato fare una cosa del genere:
public static class RGBColor
{
public static int Red = 1;
public static int Green = 2;
public static int Blue = 3;
}
Invece è preferibile creare un enum:
public enum RGBColor
{
Red,
Green,
Blue
}
Evitare di utilizzare gli enum per rappresentare insiemi aperti, ovvero insiemi i cui elementi possono variare di numero nel tempo. Ad esempio, evitare di creare un enumeratore per rappresentare le versioni di un sistema operativo. La modifica di un enum infatti può causare interruzioni con il codice già esistente.
Continua a leggere Linee guida nella scrittura di codice #05: Gli Enum
Categoria: Microsoft Dev | Permalink | Commenta
Linee guida nella scrittura di codice #04: Classe o Struttura?
Mercoledì 24 Ottobre 2007 - 09:26
di Gianni Malanga

Come sappiamo, le classidifferiscono dalle strutture per il fatto che le prime sono dei tipi reference mentre le seconde sono tipi value (definizione). Le differenze quindi sono abbastanza signficative ma vi sono diversi casi in cui una classe può essere sostituita da una struttura lasciando inalterato il comportamento dell’applicazione.
Sostituire una classe con una struttura apporta notevoli vantaggi se consideriamo che una struttura essendo memorizzata nello stack viene trattata molto più efficacemente di una classe che invece ha a che fare con lo heap. Inoltre una struttura viene subito disallocata non appena termina il suo ambito di validità mentre le classi devono attendere il passaggio del Garbage Collector per essere rimosse dalla memoria.
Continua a leggere Linee guida nella scrittura di codice #04: Classe o Struttura?
Categoria: Microsoft Dev | Permalink | Commenta
Linee guida nella scrittura di codice #03: Nomi di classi, interfacce e strutture
Lunedì 22 Ottobre 2007 - 08:37
di Gianni Malanga

Continuando con le regole di naming, vediamo oggi le linee guida per assegnare il nome a classi, interfacce e strutture.
I nomi dei tipi dovrebbero essere sempre dei predicati che definiscono l’entità rappresentata dal tipo (es. Cliente, File, Ordine, Queue…).
I nomi dei tipi devono sempre essere scritti in Pascal case e non devono includere alcun prefisso, eccetto il caso particolare delle interfacce che dovrebbero sempre iniziare con la lettera I maiuscola ( IDisposable, IComparable, IConvertible, …).
Le classi che derivano da una classe base dovrebbero terminare con il nome di quest’ultima. Ad esempio, nel framework tutte le eccezioni terminano con Exception in quanto derivano dalla classe base Exception (ApplicationException, SystemException, …).
Continua a leggere Linee guida nella scrittura di codice #03: Nomi di classi, interfacce e strutture
Categoria: Microsoft Dev | Permalink | Commenta
Linee guida nella scrittura di codice #02: Nomi di membri e tipi
Giovedì 18 Ottobre 2007 - 08:21
di Gianni Malanga

Al pari delle classi e delle interfacce è molto importante assegnare i giusti nomi a metodi, proprietà, eventi, campi pubblici e privati.
Per quanto riguarda il nome dei metodi è opportuno utilizzare sempre verbi in quanto i metodi per definizione agiscono sui dati e quindi compiono un’azione che se opportunamente sintetizzata nel nome permette di comprendere immediatamente il funzionamento del metodo stesso.
I nomi delle proprietà dovrebbero essere dei nomi o aggettivi in quanto le proprietà contengono dati e quindi un nome o un aggettivo aiuta a comprendere il significato del dato esposto dalla proprietà. Evitare di nominare una proprietà con nomi già utilizzati per identificare i metodi Get. Ad esempio evitare di chiamare una proprietà Cliente se già esiste un metodo GetCliente.
È buona norma assegnare alle proprietà di tipo bool nomi del tipo: CanRead, CanWrite, CantRead, IsOpen, HasChild, etc.
Continua a leggere Linee guida nella scrittura di codice #02: Nomi di membri e tipi
Categoria: Microsoft Dev | Permalink | Commenti (3)










