Iniziare a programmare da zero non è facile. Gli errori da principiante nella programmazione non si contano.
E così ti ritrovi a pensare…
Se solo avessi saputo prima quali errori evitare!
Bene, eccoci qui:
Una lista degli errori più frequenti fatti dai programmatori alle prime armi.
E anche se hai già passato la fase da principiante, sappi che questo ti riguarda lo stesso:
Molti di questi errori infatti possono continuare a riproporsi anche più avanti nella carriera di un programmatore…
Insomma, se li conosci li puoi evitare!
Iniziamo quindi con i 18 errori da non fare nella programmazione.
L’errore più frequente: cambiare sempre
Quando inizi a migliorare in qualcosa, è proprio lì che inizi a perdere la concentrazione.
Un linguaggio di programmazione, un framework, un software: appena ti senti a tuo agio, ecco che arriva il pensiero tentatore. E vuoi iniziare ad imparare qualcos’altro.
Il problema è che questa abitudine non ti lascia: ogni volta che inizi a muoverti con un certo grado di familiarità in un determinato ambito, cercherai la sfida in un altro campo. Ma così facendo ti accontenti di una conoscenza limitata di tante cose, senza davvero approfondirne nessuna.
E quando arriverai a sviluppare progetti complessi, ti renderai conto che è meglio padroneggiare in profondità un paio di linguaggi di programmazione, anziché conoscerne in modo superficiale una dozzina.
Trascurare la pratica di codifica
Il problema di cambiare linguaggio troppo spesso è che non puoi esercitarti quanto dovresti.
E l’esercizio pratico è quello che ti fa davvero imparare un linguaggio di programmazione.
Praticare ciò che impari è forse la parte più importante di tutta la programmazione: è quello che ti aiuta davvero ad affinare le tue capacità di problem solving – e quindi di programmazione.
Te ne accorgi subito se provi ad affrontare un problema in un linguaggio che hai studiato nel passato:
Se l’hai solo studiato, le possibilità che tu debba studiarti di nuovo tutto da capo sono molto alte. Senza contare il ritardo che accumulerai nello studio che stai portando avanti sul nuovo linguaggio.
Se invece quel linguaggio l’hai praticato a fondo, le dinamiche saranno arrugginite, ma le avrai sulla punta delle dita – per recuperarle ti basterà scaldarle giusto un po’.
Troppa teoria di codice
Ci sono alcuni programmatori principianti che si affidano troppo alla teoria. Guardano lezioni, video e tutorial, prima di mettersi a codificare. E fin qui tutto bene. La questione è che il momento in cui ci si sporca le mani con il codice sembra non arrivare mai.
E questo è un problema, soprattutto per chi sta iniziando a programmare. Infatti esiste un’enorme differenza tra leggere la teoria della programmazione e programmare codice alla mano.
È relativamente facile dirsi di aver capito tutto, ma una volta che inizi a scrivere il codice lacune, dubbi ed errori verranno alla luce.
All’inizio sembreranno tantissimi, ma dovrai continuare a esercitarti, individuare gli errori, farne il debug e ricominciare da capo, fino a quando tutto funzionerà come deve.
L’errore del principiante: non sentirsi all’altezza
Errore tipico del programmatore principiante: credere di non essere abbastanza.
Non abbastanza bravo o abbastanza intelligente, con una mente non abbastanza analitica o creativa, senza abbastanza logica o memoria.
E poi vedi gli altri, e tutti ti sembrano troppo: veloci, bravi, ninja, guru, superhero.
Non importa: chiunque può trovare la propria strada per raggiungere un certo livello di capacità nella programmazione.
La prima volta che vedi una pagina di codice ti sembrerà familiare tanto quanto il cuneiforme babilonese. Ed è giusto così, il primo impatto è uguale per tutti.
Ma non sarà così per sempre. Dopo qualche sano periodo di studio, riguarderai quella stessa prima pagina di codice, e ti stupirai di quanto facile ti sembri in quel momento.
Trascurare la formattazione del codice
Sai cosa urla “questo è codice scritto da un principiante”?
La formattazione disordinata.
Indentazione casuale, spazi non coerenti, righe bianche. Tutto questo indica un programmatore inesperto, che pensa che l’ordine non sia fondamentale.
Molti linguaggi non pongono restrizioni sulla formattazione del codice, perché l’interprete è in grado di leggere correttamente il codice in ogni caso.
Quello che i developer senior sanno, ma i junior no, è che la formattazione non serve tanto ai programmi, quanto ai programmatori. Infatti sono loro che devono capire dove iniziano e dove finiscono condizioni e funzioni, quali elementi sono contenuti e quali esclusi, in modo da capire se il codice è a posto.
E ricordati questa massima di un saggio programmatore…
Codifica sempre come se il tizio che deve manutenere il tuo codice sia un violento psicopatico che sa dove vivi (John Woods).
La programmazione non è solo scrivere codice e farlo funzionare, il tuo codice dovrebbe essere pulito, leggibile e gestibile, quindi cerca sempre di scrivere codice ben strutturato.
Usare maiuscole e minuscole a caso
Come per la formattazione, anche per l’uso delle maiuscole e minuscole succede un po’ di tutto. Alcuni linguaggi di programmazione sono case sensitive, altri no. Ma il punto fondamentale è che bisogna essere coerenti.
Anche perché poi succede – è successo, e succederà – che si passino ore facendo troubleshooting di una funzione che sembra perfetta.
Sembra.
Salvo poi accorgersi che l’unica cosa che non la fa andare è l’uso diverso di maiuscola e minuscola (myVariable vs myvariable).
Non seguire regole di naming
Esistono due tipi di programmatori: quelli che danno nomi sensati alle proprie variabili, e quelli che danno nomi a caso – chi sigle, chi codici numerici, chi semplicemente le chiama Pippo (INPS, ti ricorda qualcosa? o.O ).
Solo chi non ha ancora avuto il discutibile piacere di passare ore a cercare di capire qualcosa nel proprio codice vecchio di sei mesi a causa di variabili nominate a caso, può non avere una propria convenzione su come nominare le variabili.
Scherzi a parte, ci sono buoni motivi dietro la necessità di usare nomi di variabili descrittivi:
Innanzitutto lo scopo del codice diventa molto più chiaro, per te che ci stai lavorando e per tutti quelli che ci metteranno le mani dopo di te. Inoltre, diventa meno probabile che lo stesso nome venga usato per due variabili diverse.
Altro punto fondamentale è la grammatica: serve proprio a poco usare nomi estesi e descrittivi per le variabili, se poi dentro c’è un errore di grammatica – perché a quel punto devi anche ricordarti la versione con il tuo errore. Stesso discorso si applica a slang, e a qualsiasi flessione diversa dalla forma regolare del nome.
L’errore della codifica commentata e non cancellata
Un’altra cosa tipica dei programmatori junior è che non cancellano il proprio codice, anche se non serve. Non lo cancellano, ma lo commentano.
“Non si sa mai”.
Vero, ma poi ti ritrovi con programmi da migliaia di linee di codice, di cui però la metà è commentata.
E attenzione, non commenti utili – un codice ben commentato è sempre una meraviglia per gli occhi -, ma commenti di cose che semplicemente non vengono usate, ma non sono state cancellate.
Cancella senza paura.
E magari usa uno strumento di controllo versione per essere in grado di recuperare sempre il tuo codice.
Documentare ogni singola funzione del codice
Dunque una sana pratica di commento del codice fa bene.
Ma serve commentare solo le cose davvero utili, ovvero funzionamenti specifici del programma, flussi di informazioni complessi, soluzioni per problemi specifici che potrebbero non essere ovvie.
Il punto è proprio questo:
Commentare ciò che potrebbe non risultare ovvio, o evidente a chi dovesse guardare il codice per la prima volta.
Il che significa che non si devono commentare i funzionamenti comuni del codice – insomma devi documentare il tuo codice, ma non spiegare ogni singola regola di funzionamento della programmazione.
Non fare il backup del tuo lavoro
“Ho appena perso N ore di lavoro!”.
Questa frase.
Non la dovresti.
MAI.
Pronunciare.
Non perché speri di evitarti quel poco simpatico pomeriggio di lacrime e sangue sulla tastiera, a maledire i nuovi american gods della tecnologia.
No.
Semplicemente perché hai tutti gli strumenti a disposizione per evitare che accada.
Infatti al giorno d’oggi ci sono un gran numero di tool, anche open source e gratuiti, per il backup automatico e il controllo delle versioni.
Per questo non hai più scuse, niente può fermarti: non la coca-cola sulla tastiera, non l’hard disk che prende fuoco, non gli alieni che ti rapiscono, non Elon Musk che ti chiama, niente.
Pensare di aver imparato tutto
Questo è un errore non tanto dei principianti assoluti, quando di chi ha già avuto a che fare con la programmazione per un po’, ed è riuscito a scrivere qualche codice che funziona.
È un momento entusiasmante, anche esaltante.
Finalmente il computer fa quello che gli dici!
Ed è giusto che sia così.
L’errore è farsi prendere la mano, e pensare di aver raggiunto la vetta. Pensare di aver imparato tutto quello che c’era da imparare.
Sbagliato.
Nel modo più assoluto.
Perché se anche avessi davvero imparato tutto quello che serve fino a quel momento (ma è davvero così?), il giorno dopo ci sarebbero nuove cose da imparare. La programmazione è una disciplina in continua evoluzione:
Lei non si ferma mai, perché dovresti fermarti tu?
Scrivere codice senza pianificare
Questo è un errore che fa chiunque in qualunque campo, perché rientra in una macrocategoria di errore decisamente diffusa.
Può essere riassunto così: cercare la risposta senza aver ragionato sulla domanda.
Invece di partire in quarta a scrivere codice, devi essere sicuro di aver capito tutti i termini del problema, e di sapere cosa serve programmare per risolverlo.
In altri termini, ecco cosa serve sapere prima di iniziare a programmare:
- specificare i requisiti (cosa deve fare il programma?)
- progettare il programma (come lo deve fare?)
- progettare l’interfaccia (come lo si usa?)
- progettare i test (come verificare se funziona?)
Ricorda quindi, una corretta pianificazione ti può evitare di sprecare ore e ore di programmazione!
Non utilizzare un debugger
Un debugger è uno strumento fondamentale per programmatori principianti e non. Consente infatti di esaminare nel dettaglio il codice per capire esattamente cosa sta facendo.
Chiaramente, si tratta di uno strumento basilare per individuare dove si verifica un errore in un programma che non funziona.
Quello che non risulta così evidente a chi sta iniziando a programmare è quanto sia utile anche per i programmi che sembrano funzionare.
Infatti non sempre un risultato corretto è frutto di un processo corretto.
Rivedere il processo di esecuzione di una funzione ti permette infatti di controllare proprio questo, che a prescindere dal risultato, il funzionamento sia proprio quello voluto.
➤ Scopri i migliori tool DevOps da conoscere!
Non mantenere un log del programma
Un programma deve registrare ciò che sta facendo.
Altrimenti come farai a capire cosa non funziona, se l’unica cosa che sai è che “non funziona”?
Ecco allora che un buon log di sistema ti risolve la vita:
Tornare all’orario in cui si è verificato l’errore, e passare in rassegna il log ti può dare alcune informazioni importanti.
In questo modo puoi capire qual è stata la richiesta fatta, se ha funzionato e in che modo. Se anche non trovassi le informazioni per risolvere direttamente il problema, puoi capire i termini del problema per replicarlo negli ambienti controllati di test, studiarlo e risolverlo definitivamente.
Scrivere singole, enormi funzioni
La tentazione di chi inizia a programmare è scrivere una sola funzione onnicomprensiva.
Invece questo è un errore.
È un errore non solo perché rende difficile la lettura e il debug della funzione monstre, ma anche perché rende difficile per qualcun altro seguire quello che stai facendo. Insomma, ti metti nei casini da solo, e incasini chi vuole aiutarti.
Al contrario, dovresti avere una funzione specifica per ogni azione eseguita dal tuo programma. Insomma, divide et impera sul tuo codice.
Non convalidare gli input dell’utente
Quando si scrivono i primi programmi, l’ultima delle preoccupazioni è senza dubbio il controllo degli errori nell’input dell’utente.
Fino a quando l’utente non inserisce un singolo valore che interrompe l’intero programma.
Ecco, a quel punto capisci quanto è importante validare gli input. Verifica la presenza di errori ogni volta che devi leggere un valore, e nel caso in cui non sia valido, scrivi un semplice messaggio all’utente e richiedi un nuovo valore.
E il tuo programma sarà salvo.
Non fare pause
Ricordati, potrai anche essere un geek fino al midollo, ma resti sempre un essere umano. E la tua schiena, il tuoi occhi, il tuo cervello hanno bisogno di pause.
Alzati, sgranchisciti, bevi, mangia, guarda fuori dalla finestra, stacca il cervello per un attimo.
Soprattutto chi è agli inizi della programmazione, si butta a capofitto nella codifica, e si perde a tal punto nel codice da dimenticarsi di tutto il resto.
E invece oltre un certo livello si va in saturazione, e sostanzialmente inizi a sprecare il tuo tempo e le tue energie.
Sono le pause che ti aiutano a performare al massimo: prova a darti 5 minuti di pausa di tanto in tanto, e poi guarderai al codice con occhi nuovi!
Avere l’atteggiamento sbagliato riguardo ai bug
Molto spesso i programmatori principianti non riescono a sopportare i bug. Ma questo è un errore.
I bug sono una buona cosa.
Lo sono, perché ti indicano una chiara direzione. Ti dicono cosa stai sbagliando, e ti offrono la possibilità concreta, immediata, di migliorarti.
Per questo è fondamentale avere il giusto atteggiamento nei confronti dei bug quando inizi a programmare. Ti stanno indicando la strada per progredire!
Eccoci alla fine della lista degli errori dei programmatori principianti:
Se li conosci, li puoi evitare, diventando un developer migliore!
Ah, e sai qual è l’errore più grave per i programmatori?
Non essersi ancora iscritti a GeekandJob 😀 fortuna che puoi rimediare subito!