Maurizio's blog 3.0

Some time ago I started writing a series of blog post (only one for precision) about some “absurd” code I meet in my daily work.

I called this series “Coding horror”, and, so far I have written only one post, this one.

This is the second one.

About the code below, I thing that every comment is unnecessary because it speaks for itself.

if (myVar == null)
    return myVar = null;

As an additional reason, the Resharper tooltip about the row number 2 is:

“Destination has the same value before assignment”.

It could not be much clearer than that.

– Super cool MSBuild Debugging in Visual Studio IDE
Questa è una feature eccezionale non ufficialmente supportata. Seguendo il link è possibile scoprire i passi necessari per abilitarla in Visual Studio 2010.

– Tool di migrazione VB6 –> VB .NET / C# gratuito
Considerato che è gratuito e che promette bene vale sicuramente la pena provarlo.

– Visual Studio 2010 Dark background
Add-in per VS 2010 per impostare dei temi personalizzati circa i colori, tra cui un fantastico Dark

– Microsoft ADO .NET Entity Framework Feature CTP4

– Domain Driven Design di Alberto Brandolini  Part 1; Part 2; Part 3

– Domain Model Pattern (Martin Fowler)

– ASP.NET Multi-Level Drop Down Menu – JQuery

– NUnit Result Manager
Web application per tener traccia dei risultati degli unit tests (per project manager & developer)

Sono sempre stato piuttosto “maniacale” nella scrittura di codice, circa il rispetto delle guidelines e circa uno stile di codifica che aiuti a migliorare la leggibilità dello stesso, e la sua manutenibilità.

Ho sempre sostenuto che il pezzo di codice scritto stilisticamente bene è quello che si “autodocumenta” semplicemente solo leggendolo.

La leggibilità aumenta, a mio parere, anche con opportuni accorgimenti o tecniche, non sempre utilizzati da tutti, anzi spesso ci sono pareri discordanti sull’effettiva utilità di alcune modalità di scrittura.

Mi riferisco, ad esempio, all’utilizzo delle parentesi graffe in alcuni casi particolari dove possono essere evitate (ovviamente il contesto è quello di applicazione scritta in C#, linguaggio principe nel mondo .Net).

A mio avviso, la leggibilità beneficia del fatto di scrivere qualcosa del genere:

if (condizione)
    a = 1;

rispetto a questo codice:

if (condizione)
   {
     a = 1;
   }

Quando mi ritrovo a svolgere code review oppure solo a guardare codice scritto da altri, la tentazione di eliminare le graffe è troppo forte, e, quando posso, finisco per toglierle.

La stessa tecnica la applico al ciclo for, ovviamente anche in questo caso l’istruzione da eseguire deve essere una sola.

Circa le if, sarebbe addirittura più valida l’idea di toglierle proprio, in perfetta aderenza ai principi della campagna anti-if, a cui ho aderito con entusiasmo, anche se qui il contesto è differente poichè le “if” andrebbero usate con parsimonia o evitate del tutto quando particolarmente annidate e ripeture (così come l’istruzione “switch”),  sostituendole con una applicazione più rigorosa dei principi della programmazione ad oggetti, polimorfismo ed ereditarietà in primis.

Il pattern “Decorator” appartiene alla famiglia dei design pattern della GoF (Gang of Four), ed è classificato come pattern strutturale. E’ un pattern molto semplice da usare, che permette di aggiungere dei comportamenti personalizzati, e quindi delle responsabilità, ad una certa classe senza per questo utilizzare tecniche di subclassing.

Immaginiamo di avere un componente per il log delle informazioni. Esso invoca un servizio di logging e rispetta questo contratto definito mediante una semplice interfaccia:

public interface ILogger
{
    void Write(Exception ex);

}  
public class Logger : ILogger
{
   public void Write(Exception ex)
   {
      Console.WriteLine(ex.Message);
   }
}

Abbiamo la necessità di aggiungere una informazione aggiuntiva al messaggio di log, ovvero la data odierna. Questo significa aggiungere responsabilità alla classe, ma per ottenere questo non intendiamo nè modificare la classe originaria, nè usare il subclassing. Il design pattern “decorator” permette di ottenere questo risultato in un modo molto semplice:

public class LoggerDecorator : ILogger
{
   private ILogger loggerObj;
  
   public LoggerDecorator(ILogger logger)
   {
        loggerObj = logger;
   }

public void Write(Exception ex)
{
       Console.WriteLine(DateTime.Now.Date.ToShortDateString());
       loggerObj.Write(ex);
}

Il “decorator” consiste in una classe che implementa la stessa interfaccia della classe originaria, e con un costruttore che accetta come parametro una istanza di quest’ultima. L’implementazione dell’interfaccia permette al “decorator” di iniettare codice aggiuntivo prima ed anche dopo l’invocazione del corrispondente metodo della classe estesa.

Esempio di utilizzo:

E’ importante notare che la classe estesa (Logger in questo caso) non sa assolutamente nulla che un’altra classe è usata come “decorator”.

Nonostante la semplicità e l’utilità di questo pattern è opportuno ricordare che con l’introduzione degli “extention methods” a partire dalla versione 3.5 del .Net Framework è possibile estendere una qualsiasi classe senza usare l’ereditarietà e con l’indubbio vantaggio di ritrovarsi gli extention methods di un tipo visibili nell’Intellisense di Visual Studio.

Esempio con l’extention method:

 public static class LoggerExtention
 {
     public static void WriteData(this Logger logger)
     {
         Console.WriteLine(DateTime.Now.Date.ToShortDateString());
     }
 }
   
// Utilizzo:
Logger loggerEx = new Logger();
loggerEx.WriteData();