/dev/random

I mali del mondo (secondo un sistemista/programmatore)

Ovvero le cose da evitare come la peste, le guerre, le carestie, la droga, ecc.

Quando una persona diventa programmatore o sistemista, la maggior parte delle volte viene affascinato da cose a cui non dovrebbe nemmeno pensare. Un cristiano potrebbe chiamarle “tentazioni demoniache”, un buddista “ricchezze terrene”, ecc. ecc. Invece sono da evitare il più possibile, e da abbandonare per poter raggiungere la Vera Illuminazione. Vediamone qualcuna.

chmod 777

Questo semplice mantra (che per i file può anche essere “chmod 666”, notate il numero diabolico) permetterà a chiunque di andare a letto con la vostra ragazza, di venire a cena a casa vostra in qualsiasi momento, di “prendere in prestito” la vostra macchina, di leggervi la posta direttamente dalla cassetta, ecc. ecc. ecc.

Seriamente: Questo semplice comando permette, su sistemi Linux e Unix, di accedere a qualsiasi risorsa (a un file, in realtà, ma in Unix/Linux TUTTO è un file) senza alcuna limitazione. Guardatevi da esso, poiché è il male. A parte dare il permesso di esecuzione (che nelle directory serve per poterci entrare, ma nei file rende eseguibile il file stesso) concede pieni poteri sul file a qualsiasi utente: lettura, scrittura, modifica, azzeramento. Forse l'unica cosa che non si può fare è cancellarlo (servono permessi equivalenti sulla sua directory). Può sembrare che risolva tutti i propri problemi (non devo più diventare root per modificarlo!), ma ci sono un sacco di motivi per cui Windows è pieno di virus e Linux no. Il fatto che le distribuzioni non usino mai chmod 777 è uno di questi.

Se un fiile ha un certo set di permessi è proprio perché nessuno, per errore o intenzionalmente, lo modifichi. Aprendo in questo modo i permessi di accesso si consente a programmi impazziti, a servizi bucati da cracker o semplicemente a un errore di digitazione di fare danni seri. Pensate a quale sia la differenza tra un “rm -Rf /” dato da utente (cancella solo i file a cui ha accesso l'utente, quindi solo la sua home e pochi file in /tmp) e dato da root (cancella tutto il sistema operativo).

goto

Qui entriamo nel campo della programmazione. Ormai è risaputo che goto è la fonte di tutti i mali, l'anticristo, il limone sulla Nutella. Lo dicono perfino Dijkstra e Wirth! (I link sono alla Wikipedia italiana, ma quella inglese è più completa). goto vi farà uscire di strada in macchina (goto fosso), vi farà entrare nello sgabuzzino invece che in bagno (goto bin). Potreste perfino finire a letto con un uomo invece che con una ragazza (goto man)! Attenti!

Seriamente: goto, se usato male (e nel 99% dei casi viene usato male) rende “spaghetti-code” i vostri programmi. Fa perdere velocemente il flusso logico delle procedure/funzioni, e porta a errori inaspettati (“ma questo codice non doveva essere eseguito quando questa variabile ha questo valore!”). Linus Torvalds lo può usare perché lui sa quello che fa.

global

Qui parlo in generale delle variabili globali. C'è un motivo per cui sono state inventate la programmazione strutturata e quella ad oggetti. Le variabili globali sono una macchina del tempo rotta, che ci porta solo indietro di 50 anni: guerra (o primo dopoguerra), malattie, dispersi, fame, ecc. ecc.

Seriamente: usare variabili globali è pericoloso quanto e forse più che usare goto: queste variabili possono venire modificate da altre funzioni che non c'entrano niente con quello che stiamo facendo, ed è impossibile sapere con esattezza, guardando il codice, che valore hanno in un certo punto. Passate valori alle funzioni, impostateli in qualche variabile di classe, ma guardatevi sempre dall'usare variabili globali. Hanno senso solo in pochissimi casi, e, se siete dei principianti, in NESSUN caso.

In PHP questo comprende anche l'uso di register_globals. Questa direttiva (che per fortuna verrà disabilitata e sarà reso impossibile abilitarla conla versione 6 di PHP) prende tutte le variabili che arrivano dall'esterno del vostro script (quindi GET e POST, i cookies, i valori in sessione, le variabili d'ambiente) e le mette tutte in un minestrone, rendendole variabili globali. C'è un ordine preciso di “riempimento” di questo minestrone, ma vi sfido a capire, a colpo d'occhio, se una variabile sia stata passata da GET o se arrivi dalla sessione dell'utente. Molto meglio usare le superglobals: $_GET, $_POST, $_COOKIES, $_SESSION e $_ENV (oltre a $_SERVER).

addslashes()/stripslashes()/magic_quotes

Qui si parla specificatamente di PHP. Il giorno che queste funzioni verranno tolte da PHP probabilmente smetterà di piovere folgore dal cielo, o più probabilmente un'infinità di pagine web l'una coi caratteri più sballati dell'altra, e parecchi casi di SQL-injection spariranno dalla rete.

Seriamente: poche cose in una pagina web hanno bisogno delle barre prima di un carattere. Può sembrare giusto prima di infilare una stringa in MySQL (per cui la ‘ è un carattere speciale e, se contenuta in una frase, fa “escapata” con '), ma, per esempio, in PostgreSQL il modo giusto di fare l'escape è ” (due virgolette singole) e non ', quindi i vostri script non funzioneranno cambiando DB. Usate mysql_real_escape_string(), pg_escape_string() o, meglio ancora, PDO o un framework come Zend Framework. Per passarle su un URL (un link con <a>, per esempio) la funzione giusta è urlencode(). addslashes non è quasi mai la risposta giusta. Vale la stessa considerazione di global: se siete principianti, addslashes() non è MAI la risposta giusta.

font, b, i, frame (guest stars: table, br)

Entriamo nel mondo del web dalla porta sul retro: HTML. Il poveretto era nato con buonissime intenzioni: l'ipertesto, la digitalizzazione e il collegamento delle informazioni, la diffusione della cultura. Ma tre bambini cattivi (non facciamo nomi, solo iniziali: MS, NS e MM) gli hanno regalato le caramelle fuori dalla scuola, e da allora si sta disintossicando in diverse comunità di recupero. Per fortuna ultimamente ha trovato un bel po' di amici che lo stanno tirando fuori dal tunnel, ma ci sono ancora un sacco di bambini cattivi in giro!

Seriamente: L'HTML è nato per descrivere la struttura delle informazioni, non la loro rappresentazione sullo schermo. Usare editor WYSIWYG facilita sicuramente lo scrivere pagine web, ma avete mai provato a modificare il posizionamento di un'immagine senza usare quegli editor, o ad aggiungere un'immagine in mezzo alle altre, anche CON quegli editor? Da un po' il W3C ha preso una posizione netta sulla questione: l'HTML deve descrivere solo COSA è una certa informazione, mentre il COME FARLA VEDERE è compito dei CSS. COME SI COMPORTA è compito di Javascript (o ECMAscript), e con questo il cerchio si chiude. font, b e i sono (finalmente) tag deprecati. Un testo non è “Arial 18px bold italic”, ma “titolo di sezione”, quindi <h2> (per esempio). Una frase importante non è “bold”, ma “importante” (strong) appunto! Prima si impara a usare i tag giusti, meglio è.

Ho messo come guest star <table> e <br> perché si devono ancora usare, ma solo quando è giusto usarli. Non si usa <table> per definire il layout di una pagina, ma solo per intabellare dati. Non si usa <br> per fare spazio con le righe vuote, ma solo per andare a capo senza chiudere un paragrafo (che è <p>).

Una malattia molto diffusa per chi si avvicina ai CSS è la DIVite (accompagnata dalla SPANite): quando non si sa cosa mettere, si mettono un div o uno span, dimenticando che esistono decine di tag che non usa nessuno. Una lista della spesa è <ul>, una lista di passi per una ricetta è una <ol>. Una lista di definizioni da vocabolario è <dl>. Un'etichetta da dare a qualcosa è <label>. La legenda di una tabella è <caption>. Una breve citazione è <q>, mentre una citazione lunga è <blockquote>. Un indirizzo è <address>. Ecc. ecc. Imparate a usare i tag giusti al momento giusto, e il vostro codice sarà molto pià leggibile (e modificabile, che è la cosa più importante). Quando ci sarete arrivati, date un'occhiata anche ai Microformati, tenendo conto che ci sono già estensioni per Firefox che li usano, e che in futuro saranno sempre più diffusi e richiesti. E non dimenticate di impostare il DOCTYPE corretto!

Conclusione

Per ora chiudo qui, ma sono sicuro che ho dimenticato un sacco di cose. La morale è sempre la solita: diffidate delle strade che sembrano troppo semplici. Sicuramente c'è qualcosa che non va.