(luKa)

- i metodi sono lunghi e sterminati, fanno 10 cose tutte insieme, e l'implementazione di ogni singola cosa riesce comunque a essere sparpagliara come frattaglie in un quadro di Picasso

- cicli for, while, if e switch si annidano a mille, solitamente il primo for è li sul bordo sinistro del mio LCD, la parentesi dell'ultimo for è alla fermata della metro che apetta, solitamente è qui che prendo la palla al balzo e chiedo il terzo monitor da 24''

- i nomi delle variabili sono brevi per risparmiare, il bello è che riescono comunque sempre ad essere dichiarate nel posto più distante da dove sono usate. per farsi perdonare vencono comunque usate per 2 o tre cose diverse

- le linee di codice più incomprensibili sono quelle scritte per qualche supposta (...) ottimizzazione: meglio risparmiare. sulla visibilità di variabili, metodi classi e interfacce invece tutte pubbliche che non si sa mai protrebbe servire, se sono statiche o globali meglio

- le classi contengono molte decine di metodi, oppure poco più di un solo metodo ma queste che per non essere da meno hanno bisogno di diverse chiamate di inizializzazione: la sequenza giusta di chiamate e parametri magici che servono per farla partire è comunque un mistero come quello dell'isola di Pasqua

- gran parte del codice è fatto con copia-incolla abbastanza che se devi fare una modifica dovrò poi riportarla in altre parti con la certezza matematica di dimenticarmene qualcuna. in goni caso ha passato diverse fati di modifiche e fix che se cerco ci estrarre il codice uguale in un metodo in ogni copia ci sono decine di piccole differenze in punti diversi (ancora Picasso). E le uniche due copie che sembrano uguali nascondono come nella settimana enigmistica una piccola differenza chi fa travisare completamente il senso del codice

- ci sono classi che riescono ad avere tutti insieme pezzi di SQL, di XML di Web Services, di controlli utente, di gestione degli errori run-time, di verifica delle autorizzazioni, di gestione dei testi multi-lingua e del controllo dell'input del utente. e comunque riescono ad non avere vincoli di integrità o chiavi esterne, XML schema definition su cui validarsi, eccezioni tipizzate per distinguere gli errori o uno straccio di MVC: che quando si lavora sul serio non ce mita tempo per questi giochetti!

- e quando arriva il momento di compilare e eseguire per vedere cosa fa c'è da configurare: le voci sul registri, le configurazioni su app.config e web.config insieme alle stringhe di connessione, c'e da fare la registrazione COM, che da mettere l'assembly nella GAC, che c'è scrivere la mettere la stringa configurazione sul parametro di inizializzaione del componente COM+ o MTS, da configurare WSE o WCF, IIS ... che a qualcuno non venga in mente che non ne capiamo di tecnologie

- e quando comunque prendo coraggio, faccio una modifica e provo a vedere dove ha impatto, grazie al late-binding, duck typing, Reflection, cast dinamici e variabili varian/object che al compilatore non può che dire "speriamo..." e a me resta eseguire il codice a mano i tutti i modi possibili per provare di accorgemi in tempo di un errore run-time prima che la modifica vada in produzione

@Fabio GRANDE
la cosa che faccio piu fatica e' capire il primo passo possibile per andare dalla situazione che trovo verso quella ottimale

grazie 1000 del feedback


@raffau
quella che ti fa incazzare di piu qual'e' ?

@john79

secondo me molto, seguire sempre la stesso criterio e farlo tutti nel team da un grossa spinta a rendere il codice + leggibile

per andare sul pratico e concreto ti segnalo questo libro: Clean Code
di Robert C. Martin

e qui qualche link per elencare qualche argomento/parola chiave:

uno spunto per raggruppare metodi e classi c'è in questo post Individuare le responsabilità di una classe.

per passare da un problema sul codice a una soluzione ci sono le code smell e i relativi refactoring.


dei criteri di carattere generale sono qui: Valutare Il Disegno Di Una Applicazione oltre ai principi di disegno OO