If innestati o AND?

[TizianoLappa]

La mia esperienza mi ha insegnato che indentazione e nomi variabili 'intelligenti' sono la base di tutto.
Aprire un listato e trovare nomi impossibili (e.s. pippo, appo, appoggio, a, b, c....) è allucinante. E anche trovare un codice non indentato in modo corretto lo è altrettanto.
L'indentazione ti da a colpo d'occhio un'idea di quello che succede nel codice.

[Sjuanez]

Come in tutte le cose complesse e magari da condividere è sempre meglio avere un approccio ordinato.

Negli schemi di elettronica, progetti vari e codice. Ci sta che uno programma di frette e abbozza una cosa, ma poi bisogna ritornarci e migliorare. Certo che trovare sempre il tempo per migliorare una cosa che già funziona è una bella sfida...

[PietroBaima]

Ci sta che uno programma di frette e abbozza una cosa, ma poi bisogna ritornarci e migliorare.

Su questo non sono per niente d'accordo.
Facendo così si finisce per fare disastri, molte volte difficilmente recuperabili.
Il codice bisogna scriverlo bene da subito, e questa è una cosa che si impara.
Quando lo si è imparato diventa automatico e quindi lo si fa anche quando si è di fretta.
La cosa interessante è che poi ci si rende conto che facendo le cose bene da subito si fa prima,
quindi a maggior ragione quando si è di fretta.

Ciao,
Pietro.

[Sjuanez]

Mi riferivo al fatto che non c'è fine all'ottimizzazione del codice. Non esiste che uno butta giù un listato ed è già ottimizzato al meglio, in grado di supportare gli aggiornamenti e la manutenzione.

Per questo si suggerisce di ritornare sul codice che già funziona, magari qualche giorno dopo, e lavorare sulla modularità, sulla resilienza, su tutta l'impostazione.

A mio avviso, ci sta che uno vuole provare un metodo, una versione diversa di un algoritmo e la butta giù al volo.

Poi si rende conto di avere classi troppo grandi, nomi poco chiari o inconsistenti di variabili, codice morto, commenti non esplicativi...insomma ci siamo capiti: il codice che puzza.

Sia chiaro non sto dicendo che uno chiama la variabile pippo per andare di fretta, ma scrivere da subito il codice definitivo e ottimizzato la vedo la cosa più difficile del mondo, anche con tutto l'UML fatto a priori.

Poi se c'è qualcuno che ci riesce, ed io non conosco nessuno che lo fa, ha tutta la mia ammirazione.

[boiler]

Ripeto, probabilmente si sono impuntati per motivi didattici ma tant'è.

Io ho purtroppo notato che le scuole, anche le piú rinomate, insegnano la sintassi della programmazione, ma non la semantica.

Insomma, è come se uno straniero volesse imparare l'italiano e gli si dicesse che "Complimenti, questa pietanza è squisita" e "Ehi, figata, 'sta sbobba" sono la stessa cosa.

Riprendendo l'esempio di Sjuanez:

Codice: Seleziona tutto

$moglie_ok = $sa_cucinare && $e_bella && $ci_sa_fare;

Va benissimo se abbiamo tre variabili. Spesso però si usano funzioni che ritornano un bool. Queste funzioni a volte fanno qualcosa, scrivono un risultato in una variabile e ritornano una variabile che dice "è andato tutto bene" oppure no.

In tal caso bisogna essere coscienti del fatto che se sa_cucinare ritorna un False, le altre due funzioni non verranno eseguite. E anche se se ne è coscienti, è un pessimo stile di programmazione, perché tra due anni un'altra persona che deve fare manutenzione al codice o non se ne accorge o se ne accorge e si chiede se è voluto o una svista.

Boiler

[PietroBaima]

Proprio su questo non siamo d'accordo, purtroppo.
Scrivere funzioni piccole, ben commentate, con nomi significativi, in modo modulare, ben indentato, resiliente NON è difficile.
Si deve imparare, certo, ma una volta acquisita una buona pratica diventa assolutamente automatico.
Bisogna conoscere bene come viene interpretato il codice, certo.

Se poi vogliamo discutere dell'efficienza del codice, allora ne possiamo parlare.
Personalmente trovo che sia difficile scrivere algoritmi efficienti.
Però questo non riguarda direttamente il codice, piuttosto l'algoritmo che è alla sua base.

[PietroBaima]

In tal caso bisogna essere coscienti del fatto che se sa_cucinare ritorna un False, le altre due funzioni non verranno eseguite.

Appunto!

[TizianoLappa]

Partiamo dal presupposto che non esiste un codice perfetto.
La stessa funzione può essere scritta in mille modi, in base anche allo stile dello sviluppatore, e raggiungere lo stesso obiettivo. In tutti i casi potrebbe essere ottimizzata in funzione della casistica che viene elaborata in quel momento.
A me è capitato di scrivere codice mettendo controlli che sapevo che non sarebbero mai intervenuti o sarebbero intervenuti in casi molto rari (e.s. controlli su codici fiscali provenienti da altre funzioni. Anche se sapevo che sarebbero arrivati dati corretti il controllo l'ho aggiunto lo stesso, l'errore lo devi prevedere sempre).
Il concetto di scrivere codice chiaro e leggibile prescinde dall'efficienza della funzione che si scrive. E' una tua tutela. Se fra un anno riapriamo quel codice, indentato male e senza commenti, siamo sicuri di capire cosa fa senza perderci tempo prima di poter metterci mano?
Altra cosa che ho imparato è che una volta fatto un lavoro, difficilmente ci si torna sopra. I tempi lavorativi generalmente non te lo permettono. Una volta finito un lavoro si ha sempre qualche altra cosa di urgente da fare.

[Sjuanez]

boiler evito di quotare ma sono d'accordo. Però, oltre a commentare, spesso anche lo stile personale fa la differenza. Per questo molte aziende impongono degli stili. E ci sarebbe tutto un discorso sulla documentazione da allegare al codice, ma penso andremmo oltre.

Io per i miei progetti personali metto dei commenti, ma sono appunto personali. Se dovessi scrivere codice per altri sarebbe molto più complesso come procedimento. Tutto dipende anche dalla complessità e dalla destinazione del progetto, nonché dal budget.

PietroBaima non è che non siamo d'accordo, è che semplicemente sei più bravo ed esperto di me.

A me spesso capita di maneggiare un metodo, poi mi accordo che è diventato troppo grande e devo dividerlo. Ancora più spesso una classe mi diventa enorme e devo riconsiderarla. Oppure mi trovo che le responsabilità di tale oggetto sono diventate troppe e assomiglia troppo ad un god object. O magari che ho esagerato coi commenti.

Cose come nomi di variabili, indentazione, e strutture di controllo fortunatamente le scrivo già pensando alla leggibilità e quindi in fase di refactoring mi trovo abbastanza avvantaggiato, anche se mi capita di avere un colpo di genio a posteriori.

Si dovrebbe sempre agire in base a progetti ben documentati e vari schemi tirati giù, ma l'esperienza (non troppa) mi insegna che spesso la voglia di provare una variante è troppa e la documentazione della modifica si riduce ad un messaggio allegato alla COMMIT.

Altra cosa che ho imparato è che una volta fatto un lavoro, difficilmente ci si torna sopra. I tempi lavorativi generalmente non te lo permettono.

Questo è diverso dalla mia esperienza professionale, dove sono invece previste fasi di ottimizzazione e addirittura dei software per sistemare il codice. Ovvio che se è scritto da capre poi non va bene.

[TardoFreak]

Mah, io sono 30 anni che scrivo codice per microcontrollori, è il mio lavoro e su questo ci ho costruito una vita.
Però devo ammettere che dopo aver seguito i corsi universitari ho cambiato stile.
Per molti aspetti ho avuto conferme, per altri (a volte sorprendenti) ho cambiato opinione.
Un commento buono ed una sola linea di codice (che non sia un indovinello eh!) è meglio che pochi commenti e 5 linee di codice.
E funzioni da poche linee, modulari e chiare.

Non sono d'accordo sul tira giuù funzioni ad minkiam "solo per provare". No, o si scrive bene o non si scrive.
L' esperienza (in questo caso si, e pure tanta) mi ha insegnato che non bisogna farlo.