C# per chi vuole codice leggibile, prestazioni sensate e meno manutenzione tossica

C# non è solo sintassi: è un modo di pensare il software

Chi impara C# dal manuale impara la sintassi.

Chi lo usa in produzione per anni impara qualcosa di diverso: come il linguaggio modella il pensiero, come le sue convenzioni guidano verso soluzioni più leggibili, come le sue funzionalità moderne cambiano il modo in cui si progetta il codice.

C# non è statico.

Ogni versione introduce costrutti che riducono il rumore sintattico e rendono l'intenzione del codice più esplicita.

I record, i pattern matching, le nullable reference type, gli init-only setter, i primary constructor: non sono zucchero sintattico.

Sono strumenti che, usati consapevolmente, producono codice più difficile da usare male e più facile da leggere mesi dopo.

Quello che mi interessa di C# non è la correttezza formale.

È la leggibilità economica: codice che un collega capisce senza spiegazioni, che un manutentore può modificare senza paura, che un revisore può valutare senza contesto aggiuntivo.

Questo è il vero valore di un uso professionale del linguaggio.

Le funzionalità moderne di C#: quando usarle davvero e quando resistere

C# 10, 11, 12 e 13 hanno introdotto molte funzionalità che sembrano convenienti ma che richiedono giudizio per essere usate bene.

Il rischio opposto all'ignorarle è usarle tutte perché si può, trasformando il codice in un esercizio di stile che solo chi conosce l'ultima versione del linguaggio riesce a leggere.

Pattern matching: eccellente per sostituire catene di if/else su tipi e valori. Può diventare illeggibile se nidificato in modo eccessivo. Il criterio è: se il pattern matching rende l'intenzione più chiara, usalo; se serve un commento per spiegarlo, probabilmente è troppo complesso.

Record: perfetti per DTO, value object e dati immutabili. Non adatti per entità con stato mutabile e ciclo di vita complesso. La regola pratica è: se la classe ha solo proprietà e nessuna logica di dominio mutabile, è un record.

Nullable reference types: una delle funzionalità più impattanti degli ultimi anni. Attivare <Nullable>enable</Nullable> in un progetto nuovo costa poco e previene una classe intera di bug a runtime. In progetti esistenti richiede una migrazione graduale, ma vale l'investimento.

LINQ: potente e leggibile per trasformazioni su sequenze. Può diventare un bottleneck di performance se usato su collection grandi senza consapevolezza di cosa genera a livello di allocazioni e iterazioni.

Performance in C#: quando ottimizzare e quando fermarsi

La regola d'oro sulla performance è misurarla prima di ottimizzarla.

Molti sviluppatori ottimizzano per intuizione, spesso nel posto sbagliato, e il risultato è codice più complesso con nessun guadagno misurabile.

Gli strumenti disponibili in .NET per la performance sono eccellenti: BenchmarkDotNet per misurare, dotnet-trace e dotMemory per profilare, Span e Memory per ridurre allocazioni in hot path.

Il problema non è la mancanza di strumenti: è sapere quando usarli.

I casi in cui la performance di C# conta davvero sono: elaborazione di grandi volumi di dati, servizi ad alta concorrenza, algoritmi eseguiti milioni di volte al secondo, sistemi real-time.

In questi casi Span, ArrayPool, stackalloc e la riduzione delle allocazioni in heap producono miglioramenti concreti.

In tutti gli altri casi, la leggibilità vale più dell'ottimizzazione prematura.

Un codice chiaro che il team capisce e può cambiare è sempre preferibile a codice veloce che nessuno vuole toccare.

Async/await e concorrenza: i pattern che fanno la differenza

Async/await è una delle funzionalità più potenti e più mal usate di C#.

La sintassi è semplice; i dettagli di funzionamento non lo sono.

Gli errori più comuni che vedo nei code review: async void nei metodi che non sono event handler (causa eccezioni non catturabili), .Result o .Wait() su Task in contesti sincroni (causa deadlock in ASP.NET non-Core), dimenticare ConfigureAwait(false) in librerie (causa starvation del contesto), creare Task inutilmente con Task.Run in ASP.NET Core dove il threading è già gestito dal framework.

La concorrenza parallela con Task.WhenAll e Parallel.ForEachAsync richiede attenzione alle condizioni di gara sui dati condivisi e alla gestione degli errori parziali.

Non è difficile, ma richiede un modello mentale chiaro di cosa succede su quale thread e in quale ordine.

Il punto non è memorizzare le regole: è capire perché esistono quelle regole.

Chi capisce il thread pool, il contesto di sincronizzazione e il funzionamento del compilatore sulle state machine async non ha bisogno di memorizzare niente: ragiona e trova la soluzione.