Clean Code

Apri un file che non esiste in Python e open() lancia un FileNotFoundError che risale fuori dalla tua funzione. Fai la stessa cosa in Go e os.ReadFile ti restituisce un valore error accanto a uno slice di byte nil. Stesso fallimento, due forme di codice completamente diverse attorno ad esso. La differenza non è estetica. Decide se chi chiama la funzione può ignorare il fallimento per errore, e se il compilatore se ne accorge quando succede. ...

Una classe che salva un utente nel database, gli manda un’email di benvenuto e formatta una ricevuta è a una modifica di distanza dal rompere due funzionalità con cui non ha niente a che fare. Tocchi il template dell’email e rischi la scrittura sul database. Tocchi il layout della ricevuta e rischi l’email. SOLID sono cinque regole che attaccano questo tipo di groviglio da angolazioni diverse, e condividono un’idea sola: una classe deve cambiare per un solo motivo, e il resto del codice deve dipendere da cosa qualcosa promette di fare, non da come lo fa. ...

Ecco una classe che non puoi testare senza un database live e un server SMTP funzionante: 1 2 3 4 5 6 7 8 9 10 11 public class OrderService { private readonly SqlOrderRepository _repository = new SqlOrderRepository("Server=prod-db;Database=Orders;..."); private readonly SmtpEmailSender _emailSender = new SmtpEmailSender("smtp.company.com"); public void PlaceOrder(Order order) { _repository.Save(order); _emailSender.Send(order.CustomerEmail, "Order confirmed"); } } OrderService costruisce da sé SqlOrderRepository e SmtpEmailSender con new, connection string compresa. Ogni test che tocca PlaceOrder richiede un vero database Orders e un vero server di posta, altrimenti fallisce prima ancora che la tua assertion venga eseguita. La logica che vuoi testare sta in due righe: salva l’ordine, invia la conferma. Ma è saldata a due classi concrete che non puoi sostituire. ...

Apri una funzione per sistemare un bug di una riga e quaranta minuti dopo stai ancora seguendo quale ramo imposta quale variabile. Tre compiti che non c’entrano nulla tra loro sono saldati in un unico blocco, e nessuno dei tre ha un nome. Tiri un filo e non riesci a capire quali altri si muovono. Questo è lo spaghetti code, e il nome non c’entra niente con l’indentazione o lo stile dei nomi. Descrive il flusso di controllo: l’esecuzione salta tra le condizioni come un filo di pasta che attraversa tutti gli altri nella ciotola, e seguire un singolo percorso fino alla fine significa tenere in testa quattro livelli di if contemporaneamente. ...