Analizzando il risultato di FxCop sulle mie dll ho trovato
un po' di Warning e Errors, e queste sono le guidelines che sono risultate
dall'analisi degli issue
Regole di performance
- Per montare stringhe di testo all'interno di cicli
lunghi usare la classe StringBuilder invece che il concatenamento +=
//ERRATO
string retVal;
foreach(Language currLang in availableLanguages())
{
retVal+=currLang.code+" ";
}
return retVal;
//CORRETTO
System.Text.StringBuilder sb = new System.Text.StringBuilder();
foreach(Language currLang in availableLanguages())
{
sb.Append(currLang.code);
sb.Append(" ");
}
return sb.ToString();
- Se poi si sa a priori anche la lunghezza del ciclo
passarla come parametro nella creazione delle StringBuilder
System.Text.StringBuilder sb = new System.Text.StringBuilder(intialCapacity);
-
Per verificare se una stringa
è vuota verificarne la lunghezza, invece che compararla ad una stringa
vuota:
// ERRATO
if (s1.Equals(""))
{
Console.WriteLine("s1 equals empty string.");
}
// CORRETTO
if (s1 != null && s1.Length == 0)
{
Console.WriteLine("s1 == 0.");
}
- Evitare di inizializzare la variabili di classe ai
loro valori di default cioè:
tutti valori numerici = 0
boolean =
false
riferimenti ad oggetti = null
- Per quando possibile, ricordarsi di eliminare le
dichiarazioni di variabili non usate (es dimenticate, o similari) e soprattutto
di parametri non usati.
Regole di Naming
- Decidere le regole di naming (.NET o Java)
- Attenersi ad una lingua lingua sola, per lo meno per i nomi di variabili
"esposte" (metodi, classi e parametri)
Regole di Design
- Gestione degli errori: per evitare di "nascondere" lo stack di un'eccezione
generica quando non vi interessa gestirla usare il comando "throw" senza
parametri (che rilancia l'eccezione catchata):
try
{
outStream = File.Open(outFile, FileMode.Open);
}
catch
{
Console.WriteLine("Unable to open {0}.", outFile);
throw;
}
- Sempre sulla gestione degli errori, se nella gestione delle eccezioni è
necessario rilanciare l'eccezione, usare ancora il comando "throw" senza
paramentri per mantenere lo stack originale
// Errato
catch (SqlException sqlex)
{
throw sqlex;
}
// Corretto
catch (SqlException)
{
throw;
}
- Non esporre mai come pubblici le variabili di classe,
ma creare sempre dei metodi accessors.
- Non lasciare dei costruttori pubblici nelle classi
che contengono solo
- Non fare dei metodi "Get..." se questi metodi
ritornano solo un valore senza fare altro: al suo posto fare una propietà
- Se un metodo riceve o ritorna un'Url usare come tipo
di dati il System.Uri invece che String
- Nel creare una propria eccezione, implementarla correttamente e
completamente:
[Serializable]
public class NewException : ApplicationException //non estendere semplicemente Exception
public NewException ( )
public NewException (string message): base(message)
public NewException (string message, Exception innerException): base (message, innerException)
protected NewException (SerializationInfo info,StreamingContext context) : base(info, context)
powered by IMHO 1.1 with Emoticon Formatter
posted @ lunedì 3 gennaio 2005 16:38