Seconda storia dedicata al coding realizzata ancora una volta da Alessandro Sisti e dal sempre più carpiano Giampaolo Soldati. In questo caso il coding viene applicato alla protezione del deposito.
Chi fa da se, risparmia
E’ questa l’idea di Paperone non solo nella vita ma anche ne La ruberia condizionata. Il magnate paperopolese, la cui cartamoneta da un fantastiliardo realizzata, come gli altri paperdollari, da Stefano Zanchi, è allegata al numero di Topolino in edicola, decide di programmare da se il sistema antifurto del deposito utilizzando il coding, che avevo introdotto un paio di settimane fa in occasione della prima storia della serie.
In questo caso Sisti si concentra su due elementi essenziali nella programmazione in generale: la programmazione condizionale, che nel caso del codice di Paperone è gestita con le istruzioni se e altrimenti, e i bug, ovvero quelle situazioni in cui il programma non svolge esattamente il compito atteso. Nel caso di Paperone, ovviamente, è impedire o consentire l’accesso di un estraneo al deposito.
La storia è, inevitabilmente, semplicistica, per quanto divertente, dovendo introdurre proprio i due concetti precedenti. Vediamo, però, un esempio di codice di Scratch per la programmazione condizionata con se e allora. Il modo più semplice è quello di mostrarvi il codice del gioco del Pong realizzato con il software del MIT:
Le istruzioni qui sopra dicono al programma che, se la palla tocca la barra, allora la palla stessa deve ribaltare la sua direzione di 180° mentre il punteggio deve aggiornarsi aumentando di 1.
Nel passaggio successivo aggiungiamo anche il conteggio sulle vite:
In questo caso il “ciclo” se–allora diminuisce il numero delle vite di 1 se la palla finisce al di sotto della barra.
A questo punto, per evitare che il gioco prosegua all’infinito conteggiando anche vite negative, bisogna inserire un blocco contenente lo stop del programma nel caso in cui le vite arrivino a 0:
Tutto questo viene poi messo all’interno di un ciclo forever che permette di eseguire le istruzioni che abbiamo programmato senza la necessità di dover ogni volta lanciare il programma.
In questo caso dove potrebbe insinuarsi il bug? Ogni punto del programma può essere soggetto alla presenza di un errore: ad esempio la direzione della pallina dopo l’urto con la barra, oppure il dimenticarci di stoppare il programma quando il giocatore non ha più vite a disposizione.
Ovviamente per evitare il più possibile i bachi bisogna avere ben in mente tutte le situazioni possibili. Questo vuol dire che, quando siamo di fronte a un malfunzionamento del nostro programma, siamo costretti a pensare a tutti i modi per risolverlo, stimolando così la nostra creatività.
