Un vostro parere prima di cestinare una offerta di lavoro

di il
24 risposte

Un vostro parere prima di cestinare una offerta di lavoro

Nel processo di selezione per un posto di Sviluppatore Senior , mi è stato chiesto di scrivere una “Solution” .NET di Test. OK: fatto e consegnato.

Bene, il lavoro è stato valutato di medio basso livello!

La cosa, devo dire, mi ha sorpreso. Pensavo di aver fatto un buon lavoro e cose come queste mi fanno temere di essere come uno di quegli squilibrati che è convinto di essere Napoleone Bonaparte.
(In termini tecnici: “dunning kruger effect?”)

Vi vorrei chiedere un parere (giusto a colpo d'occhio) 

Questo è il controller che mi hanno dato


using Microsoft.VisualBasic.FileIO;
using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace CTG.DL.MeetingRoom
{
   class SaleService
   {
       public List<CTG.Task.Sale> GetSales(string path)
       {
           var result = new List<CTG.Task.Sale>();
           foreach (var file in Directory.GetFiles(path, "*.csv")){
               // Stampa delle righe del file CSV
               foreach (string line in File.ReadAllLines(path))
               {
                   var sale = new CTG.Task.Sale(line);
               }
           }
       }

       public void Run()
       {
           //proceed source files
           string[] sourceFiles = null;
           sourceFiles = Directory.GetFiles(StringUtilities.GetSourceFilePath());
           List<string[]> dataObjects = new List<string[]>();
           
           foreach (var sourceFile in sourceFiles)
           {
               dataObjects = new List<string[]>();
               using (var reader = new StreamReader(sourceFile))
               {
                   GetDataObjectsFromCsv(reader, out dataObjects, null);
               }
           }
           var sales = new List<Sale>();
           sales = GetSales(dataObjects);
           Console.WriteLine("Total records of all files: " + sales.Count());;
       }
       public static void GetDataObjectsFromCsv(StreamReader reader, out List<string[]> csvDataObjects, string filePath)
       {
           csvDataObjects = new List<string[]>();
           if (reader != null)
           {
               do
               {
                   string read = reader.ReadLine();
                   if (read == null)
                       break;
                   if (!string.IsNullOrEmpty(read))
                   {
                       read = read.Replace("\"", "");
                       string[] readArray = read.Split(new[] { ',' });
                       csvDataObjects.Add(readArray);
                   }
               } while (true);
           }
           else
           {
               var textFieldParser = new TextFieldParser(filePath) { TextFieldType = FieldType.Delimited };
               textFieldParser.SetDelimiters(",");
               while (!textFieldParser.EndOfData)
               {
                   csvDataObjects.Add(textFieldParser.ReadFields());
               }
               textFieldParser.Dispose();
           }          
       }
   
       public static List<CTG.Task.Sale> GetSales(List<string[]> dataObjects)
       {
           var sales = new List<CTG.Task.Sale>();
           List<string> fieldMappings = dataObjects[0].Select(fieldHeader => fieldHeader.Trim()).ToList();
           for (int index = 0; index < fieldMappings.Count; ++index)
           {
               fieldMappings[index] = fieldMappings[index].Replace("\0", "");
           }
           dataObjects.RemoveAt(0);
           foreach(var dataObject in dataObjects)
           {
               var sale = new CTG.Task.Sale();
               var invoiceNo = dataObject[fieldMappings.IndexOf("InvoiceNo")].Trim();               
               sale.InvoiceNo = invoiceNo;
               var clientName = dataObject[fieldMappings.IndexOf("ClientName")].Trim();
               sale.ClientName = clientName;
               var invoiceDate = dataObject[fieldMappings.IndexOf("InvoiceDate")].Trim();
               sale.InvoiceDate = DateTime.Parse(invoiceDate);
               var currency = dataObject[fieldMappings.IndexOf("Currency")].Trim();
               sale.Currency = currency;
               var amount = dataObject[fieldMappings.IndexOf("Amount")].Trim();
               sale.Amount = decimal.Parse(amount);                
               sales.Add(sale);
           }
           return sales;
       }
   
   }
}


E questo è il controller che ho realizzato

24 Risposte

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    
    using System;
    using System.Linq;
    using Vi.Tools.Extensions.Exceptions;
    using static Microsoft.IO.RecyclableMemoryStreamManager;
    namespace CTG.Task
    {
       /// <summary>
       /// The 'manager of the application.
       /// </summary>
       public static class Controller
       {
           public static void Run() 
           {
               try
               {
                   var errorPath = CTG.Task.AppSettings.ErrorFilePath;
                   var sourcePath = CTG.Task.AppSettings.SourceFilePath;
                   var archivePath = CTG.Task.AppSettings.ArchiveFilePath;
                   // The 'IO' entity 
                   var io = new CTG.Task.Types.IO(sourcePath, archivePath, errorPath);
                   // will collect only the 'sales' that have no errors on data.
                   var sales = new CTG.Task.Types.Sales();
    
                   // ========================================================================= //
                   // Broadcast communication (events) from the 'IO' object to the controller.
                   // Decouples both the entities by cutting dependencies.
                   //
                   // This prepares the ground to wire 'IO' into an external service.
                   // ------------------------------------------------------------------------- //
                   // Notifies the Controller of the new header to get confirmation
                   // that the data format is correct for the 'sale' 
                   Func<string, bool> io_onHeader = header =>
                   {
                       return CTG.Task.Types.Sale.IsHeaderOk(header);
                   };
                   // The event provides each line to be parsed by the 'sale' object.
                   // If no errors occur, the sale object adds the item to the list
                   // and sends information regarding errors (if any) back to 'IO'.
                   Func<string, string> io_onLine = line =>
                   {
                       var sale = new CTG.Task.Types.Sale(line);
                       if (!sale.HasErrors()) { sales.Add(sale); }
                       return sale.HasErrors() ? sale.Errors : null;
                   };
                   // ========================================================================= //
                   // Binds the events
                   io.OnHeader += new Types.IO.OnHeaderDelegate(io_onHeader);
                   io.OnLine += new Types.IO.OnLineDelegate(io_onLine);
                   // Starts the operations
                   io.Run();
                   // ========================================================================= //
                   // While in operation, the 'IO' object sends signals to the controller,
                   // informing it of its progress (via the two events: 'OnHeader' and
                   // 'OnLine') and requesting confirmation of data correctness.
                   // Responses from the 'Controller' are then utilized by 'IO' to manage
                   // the storage of records.
                   // ========================================================================= //
    
                   // ========================================================================= //
                   // Note: Two options have been adopted to manage communications
                   // between entities:
                   // 1) Events    for the 'IO' entity
                   // 2) Callbacks for the exchange rate
                   // Both allow the decoupling of the two entities.
                   //
                   // One option could have been to directly pass the dictionary with all
                   // the exchange rates, but this would have created a dependency.
                   // ========================================================================= //
                   // Retrives the right exchange rate for the currency: 'code' to USD
                   Func<CTG.Enums.Currencies.Codes, decimal> exchangeRate = code =>
                   {
                       return CTG.Types.ExchangeRates.ToUSD(code);
                   };
                   // Takes the best 10 performances. The ? function implements the 
                   // selction criteria normalizing all the amount to USD.
                   var take10 = sales.TakeBest(10, sale => sale.ToUSD(exchangeRate));
                   // Writes the report
                   io.ToExcell(take10, exchangeRate);
               }
               catch (CTG.Types.Warning cw) 
               {
                   cw.Log();
                   cw.Warn();
               }
               catch (System.Exception se)
               {
                   se.Log();
               }
           }    
       }
    }
    
  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    CAMBIA IL TITOLO: certi termini NON SI USANO!

    Sei un PROFESSIONISTA, per la pupattola! ;-)

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    Concordo, modifica il titolo della discussione. Non è questo il modo di esprimersi in questo forum e non lo è nemmeno per un professionista.

    Attendo modifica del titolo.

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    Ecco così va meglio 

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    OK
    Come vedi ho cambiato.
    Lasciami dire che pure l'espressione «Attendo modifica del titolo.» poteva essere formulata un pochino meglio. Anche considerato che tale titolo era stato approvato da un tuo pari.

    Detto questo entrerei nel dettaglio.
    Non so di preciso cosa sia stato contestato dal responsabile tecnico della azienda in questione 
    perchè la comunicazione è stata mediata da un recruiter.

    Cosa, vedete, che a vostro avviso, sia indice di una bassa qualità?
    (Ovviamente, punti di miglioramrnto esistono sempre. Non ho la presunzione di considerare il mio lavoro perfetto. Ma comparato con quello che era stato proposto a me sembra alquanto più strutturato.e quindi il giudizio mi ha sorpreso)

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    Cosi', I prima approssimazione, il tuo codice rispetto al precedente e' “fantascienza” ;-) 

    Probabilmente “non lo hanno capito” ;-) 

    Poi:

    1. uso di ‘var’ : taglio le dita di entrambe le mani a chi lo usa ;-) 
      Lo so, e' usato nel codice proposto MA questa e' un'altra storia ;-)
    2. uso di un mix di ‘camelCase’ e ‘snake_case’ : anche no. 
      NON E' consistente con il “code convention” del C#
    3. gestione delle eccezioni : si potrebbe fare di meglio
    4. uso di variabili locali per valori costanti/globali, visto che tali valori sono usati un'unica volta.
      Boh! Lo faccio anch'io, quindi … Poi, dentro un metodo statico! Chissa!
      Ininfluente, direi!

    .

    Pero' non capisco: un Controller con un'unico metodo statico ( "Run()" )?

    Che framework e'? Hai un link?

    Boh!

    Per esperienza, se e' vero che trovare lavoro e' difficile, e dipendi da qualcun altro, e' anche vero che devi andare a lavorare in un posto che ti ‘convince’, o almeno dove ‘senti’ di poter essere utile e che il tipo di lavoro puo' essere utile per la ‘tua’ carriera. 

    SE non ti convince, lascia perdere! Continua a cercare (compatibilmente con le esigenze finanziarie). 

    Meglio un lavoro pagato poco che da soddisfazioni che uno pagato molto dove non sei apprezzato.  

    Nella mia carriera mi è capitato 2 volte: una volta me ne sono andato dopo una settimana, ed un'altra mi avevano proposto un lavoro che fin da subito era evidente (per uno che masticava la materia) che non poteva funzionare, per cui ho declinato l'invito. L'azienda ha chiuso dopo un anno ;-) 

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    Ciao Migliorabile
    :-) Grazie della cortese risposta (ed anche grazie del commento)


    Riguardo al “var”: Anni fa ebbi un capoprogetto Tedesco. T E D E S C O: attento e pignolo, controllava T U T T O, pure il punto alla fine della frase, nei commenti. (Non è una iperbole, è vero).  
    Agli inizi, pure lui, non ne voleva sapere del “var” perchè pensava fosse l'equivalente del “Variant” del vecchio VB6. In realtà dichiarare variabili “var” è una ‘tipizzazione forte’ con la differenza che si delega il compilatore ad assegnare il giusto tipo in fase di compilazione.
    Lo scopo del var è solo quello di ‘snellire’ il codice rendendolo più leggibile: (E comunque, il correttore sintattico evidenzia lo stesso incompatibilità di tipo durante le assegnazioni di valore)

    Guarda che differenza:
                    CTG.Task.Types.Sales sales = new CTG.Task.Types.Sales();
                   System.Collections.Generic.List<CTG.Task.Types.Sale> take10 = sales.TakeBest(10, sale => sale.ToUSD(exchangeRate));

                   var sales = new CTG.Task.Types.Sales();
                   var take10 = sales.TakeBest(10, sale => sale.ToUSD(exchangeRate));

    Il “var” toglie ridondanza e allinea verticalmente le variabili (nella fase di dichiarazione) rendendole (graficamente) più leggibili.

    Riguardo lo snake_case (non conoscevo il termine) è (o almeno lo è stato) lo standard per i nomi degli "event handlers": 
    <nome oggetto>_<nome evento>
    Ho visto che citi un  standard Microsoft, dovrebbe essere questo:
    https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/naming-guidelines
    Che a sua volta fa riferimento a questo libro:
    https://www.informit.com/store/framework-design-guidelines-conventions-idioms-and-9780321545619

    Confermi?

    Riguardo Gestione delle eccezioni: Ok sicuramente. Qualche idea?


    Riguardo il punto 4, devo dire che non ho capito.


    Riguardo Il controller ha un solo metodo solo perchè quello che ho scritto è stato un esempio richiesto dalla azienda nel processo di selezione.

    È uno standard in UK (l'azienda è inglese ed il lavoro è a Birmingham) ma è una di quelle cose di una stupidità assoluta che gli Inglesi fanno e che i nostri stanno iniziando a scimmiottare.

    Infine lasciami dire qualcosa di personale. Sono un vecchio sviluppatore. ho 63 anni ed ho speso la mia vita professionale “legando il somaro dove vuole il padrone” Adesso basta. Fare fagotto abbandonare tutto ed andare di nuovo a lavorare in UK lo faccio ancora volentieri, però adesso faccio delle condizioni. Continuerò a legare il somaro dove vorrà il padrone, però stavolta la corda la scelgo io.
    La soluzione (.Net) che ho presentato è un poco “overenginered” (dovresti vedere l'intera soluzione per rendertene bene conto). L'ho fatto intenzionalmente: se (come tu dici) la capiscono, BENE c'è spazio per lavorare insieme. Altrimenti Buona fortuna!!!

    Di nuovo ciao e grazie a chi avrà voluto leggermi fino in fondo

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    La butto lì, potrebbe non essere un punto chiave ma anche sì.

    Alla luce dei 63 anni, non è che hanno deciso che gli serve un collaboratore/dipendente più giovane (e meno costoso) dando come “scusa” una valutazione del codice di prova poco obiettiva? 

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    LOL
    Voi vedè che c'hai preso?!
    (te la dico in romanesco, perchè rende meglio l'idea)

    Veramente la tua ipotesi non la avevo presa in considerazione, Ma forse avevo sbagliato!
    (Grazie Oregon, almeno hai condito questa chat con un poco di ironia)

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    @Vi61, quando ho letto l'eta' mi e' “sovvenuta” la stessa idea di @Oregon ;-)

    Giusto come curiosita':

    1. se il “tetesco di germania” era pignolo, io sarei peggio ;-)
    2. il “var” DELEGA al compilatore l'inferenza del tipo corretto. 
      Comodo per il compilatore, NON per il pisquano di turno che deve andare ad analizzare il codice. 
      SOLO i millenial (o i gen z o come cavolo si chiamano ora) sono convinti che il codice sia piu' “snello”. 
      MA siamo ONESTI: non hanno la minima idea di che cosa voglia dire programmare ;-)
      (Ho esperienze dirette giornaliere ;-))

    .

    Diciamo che “var” ha senso solo in certi casi ESTREMAMENTE limitati. 
    Ad esempio in C++ l'equivalente di “var” e' “auto” e lo uso SOLO per gli iteratori dei template, perche' specificare il tipo esatto e' un “incubo” ;-)

    Tanto per andare piu' nel dettaglio, con SOLO la seguente linea di codice:

    var take10 = sales.TakeBest(10, sale => sale.ToUSD(exchangeRate));

    di che tipo e' “take10” ????
    Devo diventare matto a capire che cosa ritorna “takeBest”…  Datemi un obice da 120 che sparo al programmatore di turno ;-)
    Codice “snello” (affermazione che NON HA SENSO) E INCOMPRENSIBILE.
    .

    Naming convention: puzzola! E' un po' che non pasticcio in C#! Ok!
    .
    Punto 4: lascia perdere, era una considerazione del “picchio”/stupidaggine!
    .
    Controller con un SINGOLO metodo statico: questa implementazione NON HA SENSO.
    In N-MILA anni di programmazione, ho usato i metodi statici per un numero ESTREMAMENTE LIMITATO di motivi, il principale dei quale e' come “factory method”. 
    Il problema e' che non puoi sostituire la classe con un'altra che magari fa qualcosa in piu'.
    .

    Quindi, vale quanto scritto sopra: meglio un lavoro pagato poco MA “interessante” che un lavoro pagato bene MA “noioso” ;-)

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    26/04/2024 - migliorabile ha scritto:


    Diciamo che “var” ha senso solo in certi casi ESTREMAMENTE limitati. 

    Magari si va un po' off-topic, ma su questo devo dire che non mi trovo un po' in disaccordo, ma proprio totalmente in disaccordo. :)

    26/04/2024 - migliorabile ha scritto:


    Comodo per il compilatore, NON per il pisquano di turno che deve andare ad analizzare il codice. 

    Per quanto mi riguarda, è comodo anche per il pisquano, visto che il tipo di dato si dovrebbe comunque evincere dal contesto e non dal tipo specifico assegnato alla variabile, ciò ancora più vero se consideriamo che nell'utilizzo di alcuni strumenti - es. LINQ, oppure un ciclo for() - prescindono dal fatto che si applichino a un array, a una lista o a un dizionario (giusto per indicare uno dei possibili scenari), ed è totalmente ridondante dover dichiarare che una istanza di Dictionary<int, string> vada assegnata a una variabile di tipo Dictionary<int, string>.

    Il dover per forza scrivere codice per esplicitare ciò che risulta perfettamente ovvio e totalmente deducibile dal contesto, è per sua definizione superfluo.

    26/04/2024 - migliorabile ha scritto:


    SOLO i millenial (o i gen z o come cavolo si chiamano ora) sono convinti che il codice sia piu' “snello”. 

    MA siamo ONESTI: non hanno la minima idea di che cosa voglia dire programmare ;-)

    Non sono solo i millennial o i Gen Z, posso garantire.
    Sulla convinzione che il codice sia più snello, c'è effettivamente una motivazione alla base di questa vaga sensazione: lo è! :)

    Se dobbiamo poi ridurre l'uso della “type inference” in un linguaggio a una tematica di scontro generazionale…

    26/04/2024 - migliorabile ha scritto:


    (Ho esperienze dirette giornaliere ;-))

    Contro l'esperienza aneddotica, nulla può! “E' successo a me”, quindi ogni altra argomentazione è del tutto superflua.

    Che poi, non vedo come questa argomentazione del “c'è gente che lo usa e non sa programmare” possa avere una rilevanza dal punto di vista tecnico: io uso abitualmente il var, per tutta una serie di motivi del tutto leciti, e non è che siccome c'è gente che pensa di saper programmare solo perché lo usa allora io smetto di farlo. Il fatto che qualcuno pensi di lavorare bene solo perché usa var è ovviamente un pensiero stupido, ma non è che quindi usarlo equivale all'essere altrettanto stupidi. :)

    26/04/2024 - migliorabile ha scritto:


    In N-MILA anni di programmazione, ho usato i metodi statici per un numero ESTREMAMENTE LIMITATO di motivi, il principale dei quale e' come “factory method”. 

    In C# (ma non solo, perché non riguarda unicamente il linguaggio), vi sono decine di motivi per cui scrivere metodi statici: ad esempio, è uno strumento per creare i cosiddetti “extension methods”, oppure è una delle scelte che rendono esplicitamente un metodo “thread safe” (non che serva essere statico per esserlo, ma se è static lo è per forza e questa caratteristica funge da “marcatore”). Vi sono poi tutta una serie di altri motivi legati alle performance.

    26/04/2024 - oregon ha scritto:


    Alla luce dei 63 anni, non è che hanno deciso che gli serve un collaboratore/dipendente più giovane (e meno costoso) dando come “scusa” una valutazione del codice di prova poco obiettiva? 

    Mi associo con questa conclusione. :)

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    26/04/2024 - Vi61 ha scritto:


    Lo scopo del var è solo quello di ‘snellire’ il codice rendendolo più leggibile: (E comunque, il correttore sintattico evidenzia lo stesso incompatibilità di tipo durante le assegnazioni di valore)

    Guarda che differenza: […]

    Il “var” toglie ridondanza e allinea verticalmente le variabili (nella fase di dichiarazione) rendendole (graficamente) più leggibili.

    Al netto dell'allineamento verticale, che non è imprescindibile e non andrebbe ricercato, concordo su tutto il resto: la leggibilità e la sintesi in un contesto dove l'informazione è ridondante sta alla base della presenza del costrutto var, ed è il motivo per cui - a differenza di altri costrutti - è stato introdotto e supportato assieme ad altre tecniche di “type inference” in altri linguaggi diversi da C# (pure in Delphi è stata aggiunta).

    26/04/2024 - Vi61 ha scritto:


    Riguardo lo snake_case (non conoscevo il termine) è (o almeno lo è stato) lo standard per i nomi degli “event handlers”

    Confermo. E' uno dei casi dove le convenzioni dell'ambiente “cozzano” con lo standard di codifica perché devono ammiccare al passato, da un lato, e dare una uniformità e familiarità con altri tool dall'altro. Si tratta di una “eccezione” talmente nota e diffusa che non costituisce generalmente un problema, quando il codice viene generato dall'IDE in alcuni contesti (tipo intercettare il clic su un pulsante in Windows Forms, per dirne una).

    Se però creo metodi da assegnare come gestori di evento a mano, scrivendo io il codice, evito almeno in quel contesto l'uso dell'underscore “_”.

    26/04/2024 - Vi61 ha scritto:


    Riguardo Gestione delle eccezioni: Ok sicuramente. Qualche idea?

    Nel tuo contesto, se quei metodi Warn() e Log() fanno quanto necessario a tracciare l'errore che si è verificato, ossia scrivono le informazioni salienti relative all'errore da qualche parte, direi che la gestione delle eccezioni è corretta, almeno in questo frangente. Nel senso che non ci sono altre cose in più che credo tu debba fare, al netto di risollevarle, ma se capisco bene l'ambito, quel Controller è il livello superiore della logica dell'applicazione, quindi qualunque eccezione non gestita diventerebbe un errore di runtime con conseguente “crash”, quindi va bene così.

    Magari sarebbe conveniente che l'eccezione non contenesse quella logica, bensì che l'eccezione diventasse un parametro da passare a un metodo che sia responsabile del log, piuttosto che codificarlo all'interno dell'eccezione, ma da quel che comprendo qui stai usando un framework già pronto e realizzato così, quindi non c'è molto che tu possa fare, direi.

    26/04/2024 - Vi61 ha scritto:


    La soluzione (.Net) che ho presentato è un poco “overenginered” (dovresti vedere l'intera soluzione per rendertene bene conto). L'ho fatto intenzionalmente: se (come tu dici) la capiscono, BENE c'è spazio per lavorare insieme. Altrimenti Buona fortuna!!!

    La parte di codice che ho visto io sino ad ora - senza nemmeno sapere a cosa serve nel dettaglio più profondo - mi sembra tutto sommato ben scritta, chiara e comprensibile. Non ci sono logiche strane, non ci sono metodi troppo complessi (anzi), le convenzioni adottate sono comunque uniformi (ripetute nei medesimi ambiti) anche quando escono dallo standard condiviso (che non è una cosa automatica e poco rilevante), in breve io nel codice non vedo nulla di sbagliato e che non possa essere comunque considerato di buona qualità.

    Tutto questo mi fa propendere ancora di più per la conclusione ventilata da Oregon… :)

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    Da millennial condivido l'osservazione di migliorabile. Il var va bene utilizzarlo, ma quello su take10 è terribile per qualcuno che deve fare review del codice e rischia di indisporlo

  • Re: Un vostro parere prima di cestinare una offerta di lavoro

    :-)

    Pensavo di essere io un bel “Talebano” ma a quanto pare non sono solo!
    Che ti devo dire? Credo che alla fine “var” sia un fatto squisitamente  personale (un po come il GoTo). Avrai notato che uso la “fully qualified naming” (Ad eccezione del ‘global’) per evocare praticamente qualsiasi cosa. 
    Quindi il mio bel livello di pignoleria ce l'ho pure io. Però, se posso, cerco di usare il var.

    Trovo ‘brutta’ e ridondante una linea di codice del tipo: 

    System.Collections.Generic.List<CTG.Task.Types.Sale> sale = new System.Collections.Generic.List<CTG.Task.Types.Sale>;

    Poi per il tipo, non mi faccio troppi problemi:
    Quando la scrivo sono ‘caldo’ e so quello che faccio, altrimenti c'è l'intelisense.

    Per il resto. Beh eviterei di usare il ‘var’ (in presenza tua) o alle brutte potrei portare dei guanti di metallo da armatura medievale a protezione delle dita!
    (Dai scherzo)

    Invece riguardo all'uso del metodo statico per il controller
    Mi ha sempre lasciato perplesso l'implementazione in un oggetto, di qualcosa che uso una sola volta.
    Perchè mai, nel Main del file Program dovrei instanziare un oggetto controller? 
    Che necessità ho di un oggetto?
    a me sebra che un bel “modulo” (di fatto della roba static) faccia benissimo al caso.

    Resta il fatto che questa considerazione non l'ho mai sviluppata troppo ed ogni riflessione in merito è sempre ben accetta
    Poi valuteremo se sarà un fatto di mero gusto personale o avra un suo solido perché


    Riguardo alla chiosa finale, più o meno concordo  

Devi accedere o registrarti per scrivere nel forum
24 risposte