Voi come leggete il codice?
Sto facendo un lavoro per una società abbastanza nota (vi dico solo che è un plugin per WP), e alcuni dei commenti fatti al mio codice dal mio referente mi hanno un po’ spiazzato: per capire cosa intendesse ho dovuto fare lo sforzo di uscire dalle mie consuetudini di sviluppo.
Dopo qualche meditazione, sono giunto alla conclusione che i nostri rispettivi approcci alla lettura del codice sono radicalmente diversi. Il mio approccio, quando prendo in mano una classe che non ho mai visto, è prima di tutto di farmi un’idea generale di cosa faccia guardando i nomi dei metodi nel class browser. Fatto questo, scendo se è il caso nel dettaglio dei metodi che mi interessano o mi sembrano cruciali per il suo funzionamento. Per me, quindi, un metodo usato una volta sola non solo ha poco senso — e ne privilegio quindi il riuso rispetto ad altre considerazioni –, ma è addirittura dannoso in quanto inquina la comprensione a colpo d’occhio del codice.
Il mio interlocutore invece segue un approccio diverso: quando prende in mano una classe guarda subito al costruttore, e parte da lì per seguire un eventuale flusso di codice. Per lui un metodo usato una sola volta ha un senso, in quanto incapsula determinate operazioni e — se il nome è scelto con criterio — nasconde parte del codice rendendo più semplice e veloce seguire un eventuale flusso di esecuzione.
Nel caso specifico (un plugin per WP) è probabile che il suo approccio abbia senso, dato che il codice viene eseguito più o meno in sequenza, anche se la sequenza è pilotata dai vari hook di WP, cui sono agganciati i metodi pubblici della classe. Certo è che lavorando di solito in Python/Django, un approccio di questo tipo mi sembra un po’ stravagante.
Sarei curioso di sapere come altri leggono il codice, e se la differenza è dovuta più al framework (WP) che porta a pensare in maniera sequenziale, al linguaggio usato, o se è soprattutto un approccio personale. BTW, questo post è scritto usando il plugin di cui sopra, secondo il principio dell’eat your own dogfood.
24 marzo 2013 #
Penso in generale di fare un misto, ma dipende dal caso.
In generale preferisco quando i metodi son corti e facilitano la lettura.
Per esempio, se un metodo consiste di tre operazioni (che richiedono piu` di 2-3 righe di codice o un branch del flusso, tipo if) facilmente estrapolabili come metodi privati e` meglio, per me, far si` che lo siano quindi avere un metodo di tre righe che chiama 3 metodi aventi nomi opportuni e che siano possibilmente dichiarati vicino al metodo che li invoca.
Questo consente di evitare un sacco di commenti (che si fa fatica a tenere aggiornati quando il codice cambia) e permette di entrare nel dettaglio molto selettivamente in fase di lettura.