-----------------------------------

Acquista i software ArcGIS tramite Studio A&T srl, rivenditore autorizzato dei prodotti Esri.

I migliori software GIS, il miglior supporto tecnico!

I migliori software GIS, il miglior supporto tecnico!
Azienda operante nel settore GIS dal 2001, specializzata nell’utilizzo della tecnologia ArcGIS e aderente ai programmi Esri Italia Business Network ed Esri Partner Network

-----------------------------------



martedì 31 marzo 2009

StyleCop & FxCop

FxCop analizza il codice compilato gestito a differenza di StyleCop che analizza il codice sorgente. Le aree che ispeziona sono: il design del codice, la localizzazione, interoperabilità, la convenzione dei nomi, le prestazioni, la sicurezza e l'uso.

Utilizzando questi strumenti, anche se può rivelarsi non sempre agevole, sicuramente avremo un codice più pulito, una scrittura standard, codice più ottimizzato ecc.

FxCop include una sua interfaccia, può essere utilizzato da riga di comando o può essere utilizzato come tool esterno in Visual Studio ( http://msdn.microsoft.com/it-it/library/bb429389(en-us,VS.80).aspx ) . Vedi impostazioni in VS 2008 ad esempio:






Le versioni correnti sono

StyleCop 4.3.1.3: http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=sourceanalysis&ReleaseId=1425


FxCop 1.36: http://www.microsoft.com/downloads/details.aspx?FamilyID=9aeaa970-f281-4fb0-aba1-d59d7ed09772&displaylang=en

Se lanciamo FXCop da menu di Visual Studio dopo averlo aggiunto come tool esterno in un progetto con questo semplice codice:

using System;
namespace varie
{
     public class Test
     {
        static void Main(string[] args)
        {
          Console.WriteLine("Hello World!");
        }
     }
}


Avremo i seguenti warning:




Questo è il codice dopo aver corretto tutti i warning:

using System;
[assembly: CLSCompliant(true)]
namespace Varie
{
    public sealed class Test
    {
        private Test()
        { }
        static void Main()
        {
            Console.WriteLine("Hello World!");
        }
    }
}


In questo semplicissimo esempio abbiamo visto come FXCop ci ha segnalato di eliminare il costruttore (ho aggiunto il costruttore privato) questo perchè il costruttore non è necessario perché la chiamata a membri statici non richiede un'istanza del tipo. Poiché il tipo non presenta membri non statici, la creazione di un'istanza non consente di accedere ad alcun membro del tipo.
Altro warning ci segnala di marcare sealed la classe questo perchè la regola presuppone che un tipo che contiene solo membri statici non sia progettato per essere ereditato perché il tipo non fornisce alcuna funzionalità sottoponibile a override in un tipo derivato. Un tipo non adatto a essere ereditato deve essere contrassegnato con il modificatore sealed per impedirne l'utilizzo come tipo di base.


In entrambi i tool è possibile aggiungere nuove regole (rules) personalizzate in modo da espandere le potenzialità di questi due strumenti adattandoli alle nostre esigenze di progetto.
StyleCop oltre ad agire sul codice sorgente è comunque più focalizzato sulla leggibilità e la documentazione del codice.
StyleCop home: http://blogs.msdn.com/sourceanalysis/



Codice corretto con le indicazioni di StyleCop:

//-----------------------------------------------------------------------
// <copyright file="Test.cs" company="Nicogis">
//     Copyright (c) Nicogis. All rights reserved.
// </copyright>
// <author>Domenico Ciavarella</author>
//-----------------------------------------------------------------------
namespace Varie
{
    using System;
 
    /// <summary>
    /// summury class test
    /// </summary>
    public sealed class Test
    {
        /// <summary>
        /// Prevents a default instance of the Test class from being created
        /// </summary>
        private Test()
        {
        }
 
        /// <summary>
        /// description main method ...
        /// </summary>
        private static void Main()
        {
            Console.WriteLine("Hello World!");
        }
    }
}

domenica 22 marzo 2009

NVI (Non-Virtual Interface) pattern

Quando si progetta una classe base specificatamente per essere utilizzata da classi che possono ereditare, si dichiarano ad esempio i metodi virtuali di modo che le classi derivate possano modificarne il comportamento.
In questo esempio eseguendo il metodo main nella console avremo come output: "Derived method".




public class EntryPoint
{
static void Main(string[] args)
{
Base b = new Derived();
b.Method();
}
}
public class Base
{
public virtual void Method()
{
Console.WriteLine("Base method");
}
}
public class Derived : Base
{
public override void Method()
{
Console.WriteLine("Derived method");
}
}
Supponiamo ora che abbiamo distribuito la nostra classe base a molte persone che hanno a loro volta utilizzato questa classe per crearsi le loro classi derivate ( la nostra classe base non è marcata sealed ed ha metodi virtuali) e che vogliamo modificare la nostra classe base aggiungendo ad esempio un tracker dei metodi per il nostro log di debug (ad esempio utilizzando log4Net). In questa forma, se dovessimo agire sul codice aggiungendo un pre e post metodo di log, dovremmo chiedere a tutti coloro che hanno utilizzato la classe base di modificare il loro codice in base alla nostra aggiunta.





public class Base
{
private static readonly log4net.ILog _log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
public virtual void Method()
{
_log.Debug("Start method");
Console.WriteLine("Base method");
_log.Debug("End method");
}
}
Per evitare questo problema possiamo modificare la classe base utilizzando il pattern NVI:




public class Base
{
public void Method()
{
CoreMethod();
}
protected virtual void CoreMethod()
{
Console.WriteLine("Base method");
}
}
public class Derived : Base
{
protected override void CoreMethod()
{
Console.WriteLine("Derived method");
}
}



In questo modo, noi possiamo cambiare la classe base senza che gli utenti che hanno creato le classi derivate debbano modificare il loro codice:


public class Base
{
private static readonly log4net.ILog _log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
public void Method()
{
_log.Debug("Start method");
CoreMethod();
_log.Debug("End method");
}
protected virtual void CoreMethod()
{
Console.WriteLine("Base method");
}
}
In sostanza, abbiamo modificato a non virtuale l'interfaccia pubblica (Method) ed abbiamo spostato il metodo overrideable in un altro metodo protetto (CoreMethod()).