Era da tanto che non dedicavo una discussione in cui si legge pura e semplice teoria. Oggi sono tornato con una discussione che ogni programmatore dovrebbe conoscere per scrivere un codice pulito, leggibile e con i contro coglioni. Inizio dicendo che quello che leggerete in questa discussione vale per qualsiasi linguaggio, sto scrivendo in questa sezione perché gli esempi che andrete a leggere e che io andrò a spiegare saranno scritti in linguaggio C.
A voi sembrerà che la stesura del codice dipenda solo dalle conoscenze dello stesso, qualunque sia il linguaggio preso in esame, in realtà non è così perciò vi dico già che questa non sarà una discussione breve. Cominciamo ? Dunque...come ogni buon libro dal quale leggete e prendete informazioni la prima cosa che risalta all'occhio è la chiarezza di quello che leggete, le parole sono scelte e le frasi sono sensate. Allo stesso modo vale per la programmazione. Non vi dimenticate che si parla di linguaggio di programmazione e come tale ne vanno rispettate tutte le regole. Per farla breve : il programmatore deve scrivere il codice come se stesse scrivendo un libro, con la differenza che il "libro del programmatore" - chiamiamolo così momentaneamente - è costituito da variabili, tipi di variabili, funzioni, classi e quant'altro. Fino ad adesso è semplice no ? Andando avanti, se io - programmatore - devo scrivere un set di istruzioni devo necessariamente conoscere il linguaggio in cui le andrò a scrivere, ecco qui che subentra la conoscenza e la voglia di imparare. Vi sembrerà banale ma la conoscenza senza la voglia di fare serve a poco; ecco perché consiglio a tutti coloro che si avvicinano al "mondo della programmazione" - mi piace chiamarlo così - di farsi un esame di coscienza e chiedersi se si è disposti veramente a impiegare del tempo per programmare. Programmare non è uno scherzo, è un gioco. Detto questo, in aggiunta alle conoscenze e alla voglia di fare il programmatore deve possedere una buona capacità logica, che cosa intendo ? Intendo che la programmazione va affrontata secondo questo criterio : ho un problema da risolvere. Possiamo dire che la matematica segue lo stesso criterio, a quanti sarà capitato di trovarsi di fronte una frazione e arrivare alla conclusione che questa - anziché calcolata - andava semplificata ? Questo è un esempio di ho un problema da risolvere : ho una frazione, cosa devo fare ? la calcolo ? no la semplifico. E' tutta logica.
Ok dai, fino ad adesso abbiamo scherzato, vi ho fatto leggere concetti che magari dopo averli letti potrete pensare "ma ovvio" e difatti è così, non appena io appresi queste cose nella mia mente ho pensato ma in fondo lo sapevo, solo che non ci avevo mai fatto caso. Basta ragionare. Adesso però concentriamoci un attimo sulla parte che riguarda veramente la programmazione. Partiamo dall'inizio ovviamente : il programmatore ha in mente di scrivere un programma - banale o complesso che sia - che cosa fareste voi per scriverlo ? Vi dico cosa farei io : come vi ho accennato poco fa la logica è tutto, ecco perché nessuno mi vieta di aprire il cassetto e prendere carta e penna. Carta e penna ? Sì esatto. Sempre come vi ho detto prima, il programmatore deve risolvere il suo problema : come scrivere il programma. Quando si ha in mente un progetto bene o male si sa cosa fare, solo che si deve fare in modo di averlo ben chiaro in mente, ecco perché il programmatore andrà a scomporre il problema principale in tanti piccoli sotto-problemi.
La figura rappresenta ciò di cui ho appena parlato. Una volta che il programmatore si è fatto un quadro chiaro di cosa andrà a fare, alla fine, gli basterà tramutare il tutto nel linguaggio in cui deve scrivere il programma.
Bene, la parte che possiamo chiamare Elaborazione del problema l'abbiamo appena terminata. Adesso, visto che il programmatore andrà a scrivere il codice diciamo qualcosa che riguarda quest'ultimo. Il codice, per chi non lo sapesse, è un set - o insieme - di istruzioni che compongono un programma. Il codice può essere scritto in tantissimi modi, modi che non hanno un nome ben preciso ma dipendono dalla logica, dalle preferenze e anche dal tipo di linguaggio in cui si scrive ( se prendete per esempio l'assembly noon potrete mai scriverlo come piacerebbe a voi ). A proposito di codice, si definisce un buon codice un set di istruzioni scritto in modo chiaro ( ovvero senza che chi lo legge debba sforzarsi più di tanto per capire quello che sta leggendo ), con la giusta logica ( che riguarda come ho detto prima le preferenze del programmatore, ma questo non vuol dire che il programmatore possa scriverlo come vuole, dipende ) e performante. Cosa intendo per performante ? Intendo dire che deve essere scritto in modo che il computer non faccia chissà quale fatica per eseguirlo, un esempio potrebbe essere quello di controllare l'input immesso dall'utente : supponendo di voler controllare se l'utente ha inserito una vocale o una consonante all'inizio potrebbe venire in mente quella di scrivere tante if quante sono le lettere dell'alfabeto e controllare se sono vocali o consonanti. Logicamente ha senso, ma visivamente e funzionalmente ? Assolutamente no. Il procedimento corretto sarebbe quello di creare un array di lettere e consonanti ( o solo uno dei due ) e ciclarli per vedere l'input dell'utente. Questo significa codice performante!; per farvi capire meglio posterò l'esempio di seguito.
Prendendo in esame l'esempio sopra citato, inizialmente potreste scriverlo in questo modo :
Posso mai fare una cosa del genere ? Certo che sì, ma NO GRAZIE. Non si può leggere...a livello logico è corretto ma a livello funzionale no, troppi else if. Ecco come lo scriverei io :
Se provate a mandare in esecuzione questo programma vi accorgerete che il testo Hai digitato una vocale o il testo Hai digitato una consonante verranno scritti 5 volte perché il ciclo for viene eseguito per il numero di volte pari al numero delle vocali, cioè 5. Non è sbagliato, c'è solo da aggiungere qualcosa ma non è questo il punto. Il punto è che mi sono fatto furbo : perché perdere tempo a scrivere un array di tutte le consonanti quando invece posso scrivere un array di sole 5 vocali e ciclarlo ? Questo significa scrivere codice performante e corretto logicamente. Come ho scritto poco fa ci sono tanti modi per scrivere lo stesso programma - questi modi sono chiamati algoritmi - dipende dal programmatore.
Un altro esempio banale che possiamo fare riguarda la scrittura di un programma che tramite una funzione restituisce la somma di due numeri. Il programma, a mio avviso, può essere scritto in due modi :
Primo modo
Se mandate in esecuzione il programma avrete come risultato 7. Io però ho mandato in esecuzione questo programma su Visual Studioo 2012 Ultimate e il linker mi ha segnalato questo errore : Errore 1 error C3861: 'somma': identificatore non trovato. Identificatore ? Di che sta parlando ? Si riferisce alla funzione somma e l'errore è dovuto al fatto che non ne ho scritto il prototipo, perciò il linker in fase di linking non sa dove andare a prendere quella funzione, daltronde non è definita da nessuna parte. Ecco come avrei dovuto scrivere il programma :
Secondo modo ( corretto )
Ecco che qui subentra una argomento molto importante che riguarda le funzioni : un codice ben scritto prevede la dichiarazione del prototipo di una funzione. Ma questo è sempre vero ? No. Alcuni IDE permettono di evitare la scrittura del prototipo, ma dal momento che Visual Studio è un IDE con i contro coglioni - per questo lo consiglio a tutti - giustamente mi segnala quell'errore, ed è bene e giusto che lo segnali. Così si programma.
Volendo potrei anche fare riferimento a molti altri argomenti per farvi capire come va scritto correttamente il codice ma spaziare in vari argomenti significherebbe fare altri esempi e non ho idea di quali esempi potrei fare, spero che quanto scritto vi sia servito per capire il succo del discorso.
PS: Per fornire un ulteriore esempio potete leggere questa discussione.
Alla prossima.
Spiegazione
A voi sembrerà che la stesura del codice dipenda solo dalle conoscenze dello stesso, qualunque sia il linguaggio preso in esame, in realtà non è così perciò vi dico già che questa non sarà una discussione breve. Cominciamo ? Dunque...come ogni buon libro dal quale leggete e prendete informazioni la prima cosa che risalta all'occhio è la chiarezza di quello che leggete, le parole sono scelte e le frasi sono sensate. Allo stesso modo vale per la programmazione. Non vi dimenticate che si parla di linguaggio di programmazione e come tale ne vanno rispettate tutte le regole. Per farla breve : il programmatore deve scrivere il codice come se stesse scrivendo un libro, con la differenza che il "libro del programmatore" - chiamiamolo così momentaneamente - è costituito da variabili, tipi di variabili, funzioni, classi e quant'altro. Fino ad adesso è semplice no ? Andando avanti, se io - programmatore - devo scrivere un set di istruzioni devo necessariamente conoscere il linguaggio in cui le andrò a scrivere, ecco qui che subentra la conoscenza e la voglia di imparare. Vi sembrerà banale ma la conoscenza senza la voglia di fare serve a poco; ecco perché consiglio a tutti coloro che si avvicinano al "mondo della programmazione" - mi piace chiamarlo così - di farsi un esame di coscienza e chiedersi se si è disposti veramente a impiegare del tempo per programmare. Programmare non è uno scherzo, è un gioco. Detto questo, in aggiunta alle conoscenze e alla voglia di fare il programmatore deve possedere una buona capacità logica, che cosa intendo ? Intendo che la programmazione va affrontata secondo questo criterio : ho un problema da risolvere. Possiamo dire che la matematica segue lo stesso criterio, a quanti sarà capitato di trovarsi di fronte una frazione e arrivare alla conclusione che questa - anziché calcolata - andava semplificata ? Questo è un esempio di ho un problema da risolvere : ho una frazione, cosa devo fare ? la calcolo ? no la semplifico. E' tutta logica.
Ok dai, fino ad adesso abbiamo scherzato, vi ho fatto leggere concetti che magari dopo averli letti potrete pensare "ma ovvio" e difatti è così, non appena io appresi queste cose nella mia mente ho pensato ma in fondo lo sapevo, solo che non ci avevo mai fatto caso. Basta ragionare. Adesso però concentriamoci un attimo sulla parte che riguarda veramente la programmazione. Partiamo dall'inizio ovviamente : il programmatore ha in mente di scrivere un programma - banale o complesso che sia - che cosa fareste voi per scriverlo ? Vi dico cosa farei io : come vi ho accennato poco fa la logica è tutto, ecco perché nessuno mi vieta di aprire il cassetto e prendere carta e penna. Carta e penna ? Sì esatto. Sempre come vi ho detto prima, il programmatore deve risolvere il suo problema : come scrivere il programma. Quando si ha in mente un progetto bene o male si sa cosa fare, solo che si deve fare in modo di averlo ben chiaro in mente, ecco perché il programmatore andrà a scomporre il problema principale in tanti piccoli sotto-problemi.
La figura rappresenta ciò di cui ho appena parlato. Una volta che il programmatore si è fatto un quadro chiaro di cosa andrà a fare, alla fine, gli basterà tramutare il tutto nel linguaggio in cui deve scrivere il programma.
Bene, la parte che possiamo chiamare Elaborazione del problema l'abbiamo appena terminata. Adesso, visto che il programmatore andrà a scrivere il codice diciamo qualcosa che riguarda quest'ultimo. Il codice, per chi non lo sapesse, è un set - o insieme - di istruzioni che compongono un programma. Il codice può essere scritto in tantissimi modi, modi che non hanno un nome ben preciso ma dipendono dalla logica, dalle preferenze e anche dal tipo di linguaggio in cui si scrive ( se prendete per esempio l'assembly noon potrete mai scriverlo come piacerebbe a voi ). A proposito di codice, si definisce un buon codice un set di istruzioni scritto in modo chiaro ( ovvero senza che chi lo legge debba sforzarsi più di tanto per capire quello che sta leggendo ), con la giusta logica ( che riguarda come ho detto prima le preferenze del programmatore, ma questo non vuol dire che il programmatore possa scriverlo come vuole, dipende ) e performante. Cosa intendo per performante ? Intendo dire che deve essere scritto in modo che il computer non faccia chissà quale fatica per eseguirlo, un esempio potrebbe essere quello di controllare l'input immesso dall'utente : supponendo di voler controllare se l'utente ha inserito una vocale o una consonante all'inizio potrebbe venire in mente quella di scrivere tante if quante sono le lettere dell'alfabeto e controllare se sono vocali o consonanti. Logicamente ha senso, ma visivamente e funzionalmente ? Assolutamente no. Il procedimento corretto sarebbe quello di creare un array di lettere e consonanti ( o solo uno dei due ) e ciclarli per vedere l'input dell'utente. Questo significa codice performante!; per farvi capire meglio posterò l'esempio di seguito.
Esempi
Prendendo in esame l'esempio sopra citato, inizialmente potreste scriverlo in questo modo :
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Posso mai fare una cosa del genere ? Certo che sì, ma NO GRAZIE. Non si può leggere...a livello logico è corretto ma a livello funzionale no, troppi else if. Ecco come lo scriverei io :
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Se provate a mandare in esecuzione questo programma vi accorgerete che il testo Hai digitato una vocale o il testo Hai digitato una consonante verranno scritti 5 volte perché il ciclo for viene eseguito per il numero di volte pari al numero delle vocali, cioè 5. Non è sbagliato, c'è solo da aggiungere qualcosa ma non è questo il punto. Il punto è che mi sono fatto furbo : perché perdere tempo a scrivere un array di tutte le consonanti quando invece posso scrivere un array di sole 5 vocali e ciclarlo ? Questo significa scrivere codice performante e corretto logicamente. Come ho scritto poco fa ci sono tanti modi per scrivere lo stesso programma - questi modi sono chiamati algoritmi - dipende dal programmatore.
Un altro esempio banale che possiamo fare riguarda la scrittura di un programma che tramite una funzione restituisce la somma di due numeri. Il programma, a mio avviso, può essere scritto in due modi :
Primo modo
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Se mandate in esecuzione il programma avrete come risultato 7. Io però ho mandato in esecuzione questo programma su Visual Studioo 2012 Ultimate e il linker mi ha segnalato questo errore : Errore 1 error C3861: 'somma': identificatore non trovato. Identificatore ? Di che sta parlando ? Si riferisce alla funzione somma e l'errore è dovuto al fatto che non ne ho scritto il prototipo, perciò il linker in fase di linking non sa dove andare a prendere quella funzione, daltronde non è definita da nessuna parte. Ecco come avrei dovuto scrivere il programma :
Secondo modo ( corretto )
Codice:
Perfavore,
Entra
oppure
Registrati
per vedere i codici!
Ecco che qui subentra una argomento molto importante che riguarda le funzioni : un codice ben scritto prevede la dichiarazione del prototipo di una funzione. Ma questo è sempre vero ? No. Alcuni IDE permettono di evitare la scrittura del prototipo, ma dal momento che Visual Studio è un IDE con i contro coglioni - per questo lo consiglio a tutti - giustamente mi segnala quell'errore, ed è bene e giusto che lo segnali. Così si programma.
Volendo potrei anche fare riferimento a molti altri argomenti per farvi capire come va scritto correttamente il codice ma spaziare in vari argomenti significherebbe fare altri esempi e non ho idea di quali esempi potrei fare, spero che quanto scritto vi sia servito per capire il succo del discorso.
PS: Per fornire un ulteriore esempio potete leggere questa discussione.
Alla prossima.
