Validare il codice è davvero necessario?

Validare il codice. É la mania di chi tende al perfezionismo e scrive il codice con un’accuratezza quasi maniacale quello di vedere il segno di spunta verde che sta ad indicare che il codice della pagina web appena sviluppata ha superato il controllo di validazione. Ma che cosa significa validare il codice? E perché conviene farlo? E ancora, è sempre necessario superare la validazione o ci possono essere delle eccezioni?

Andiamo con ordine, in quest’articolo cercheremo di rispondere a tutti gli interrogativi che ci siamo appena posti e con cui molti sviluppatori si trovano quotidianamente a combattere.

Che cosa significa scrivere codice valido o standard?

Iniziamo con il dire che cosa s’intende con l’affermazione “scrivere codice valido o standard“.

Un po’ di storia

Esiste un organismo internazionale senza scopo di lucro, composto da un gruppo di esperti che lavora da anni per standardizzare i linguaggi e le tecnologie per il Web. Tale organismo prende il nome di World Wide Web Consortium (o W3C).

Gli standard web

Il W3C nel corso degli anni ha definito degli standard che hanno il compito di definire la sintassi e i marcatori (tag) da impiegare nella costruzione di qualsiasi documento web. Di conseguenza seguendo questi standard si rendono i contenuti web più facilmente fruibili da tutti gli utenti a prescindere dal particolare browser utilizzato e in certi casi (se si sono rispettate anche le linee guida definite per l’accessibilità) anche dall’interprete in uso (ad es., browser normali, browser basati su dispositivi di sintesi vocale, telefoni cellulari, personal computer per automobili, ecc.)

Come scrivere codice valido?

Abbiamo appena detto che scrivere codice valido significa rispettare i relativi standard definiti dal W3C. Ma come scrivere codice valido?

Quando si sviluppa una pagina web, la prima cosa che si indica nel documento è il Doctype (Document Type Definition, Definizione del Tipo di Documento) che serve appunto a comunicare al browser con quale linguaggio di markup è redatto il documento.

Per scrivere codice valido bisogna accertarsi che i marcatori (tag) e gli attributi adoperati rispettino alla lettera la sintassi definita nel Doctype dichiarato all’inizio del documento.

Una volta realizzato il nostro documento web, come possiamo verificare di aver scritto codice standard?

Validare il codice: Come accertarsi di aver scritto codice valido?

Per controllare la validità del proprio codice si possono utilizzare dei software – come il Markup Validation Service offerto dal W3C – che controllano in modo automatico la correttezza e il rispetto degli standard del documento che si desidera sottoporre a verifica.

Il validatore messo a disposizione dal W3C, oltre ad indicare l’eventuale numero di errori commessi nella redazione del documento web, fornisce un valido aiuto per la correzione degli stessi segnalando la riga di codice dove è presente l’errore e descrivendone anche la tipologia. Ovviamente per capire e correggere i possibili errori segnalati bisogna comprendere il codice in modo da poter modificare all’occorrenza il codice sorgente del documento.

Una estensione per Firefox per validare il codice in tempo reale

Validare il codice del proprio documento web sul sito del validatore offerto dal W3C comporta qualche complicazione, per esempio non è possibile monitorare la validazione durante lo sviluppo del codice, a meno che non si carichi il documento web sul validatore del W3C ad ogni nuova riga di codice redatto, con conseguente enorme perdita di tempo.

Volendo è possibile risolvere questo inconveniente installando HTML Validator, un’estensione per il browser Open Source Firefox che mette a disposizione tutti gli strumenti necessari per la validazione delle pagine web direttamente sulla finestra del browser. Il plugin è basato su due algoritmi sviluppati dal W3C, Tidy e OpenSP.

Utilizzando questa estensione ogni volta che si naviga su qualsiasi documento web viene mostrato il risultato della validazione del documento direttamente nella finestra del browser, in fondo a destra, come mostrato nella foto sopra. In questo modo diventa molto più semplice validare il codice dei propri lavori.

Che cosa comporta scrivere codice valido?

Ovviamente scrivere codice standard comporta dei vantaggi, tra le altre cose il documento web sarà più facilmente fruibile da tutti gli utenti a prescindere dal particolare browser utilizzato e non è da trascurare anche il fattore “indicizzazione”, poiché gli spider dei motori di ricerca potrebbero trovare grosse difficoltà nell’indicizzare correttamente documenti web contenenti determinati errori di markup.

Un codice validato è sempre sinonimo di buon codice?

Attenzione però a non farsi ingannare dalle parole “validato” e dal risultato positivo restituito dal validatore del W3C.

Il codice di un documento web può anche essere validato ma ciò non presuppone che comunque questo debba considerarsi a priori un buon codice perché ci sono diversi fattori che un validatore, trattandosi di un software, non può valutare correttamente.

Per esempio i documenti web che soffrono di “classite” o “divite” possono anche essere validati dato che se i marcatori utilizzati per la realizzazione del documento web sono stati impiegati correttamente il validatore restituirà comunque come risultato un codice validato. Questo però non significa che è stato scritto un buon codice.

Facciamo subito un esempio pratico per cercare di comprendere meglio quello che stiamo dicendo:

<div id="titolo-grande">
    <h2>Titolo argomento</h2>
</div>

<div id="navigazione">
    <ul>
        <li>item 1</li>
    </ul>
</div>

<div class="paragrafo-rosso">
    <p>questo è un paragrafo di colore rosso</p>
</div>

Il codice scritto sopra se fosse sottoposto al controllo del validatore sarebbe valido poiché tutti i marcatori (tag) definiti dalle linee guida del W3C sono stati utilizzati in modo corretto. Ma come dicevamo, questo codice non può essere considerato un codice ottimizzato perché utilizza diversi elementi di cui si potrebbe benissimo fare a meno.

Ecco un esempio di codice ottimizzato che produce il medesimo risultato del precedente:


<h2 id="titolo-grande">Titolo argomento</h2>

<ul id="navigazione">
    <li>item 1</li>
</ul>

<p class="paragrafo-rosso">
    questo è un paragrafo di colore rosso
</p>

Come puoi vedere in questo banalissimo esempio per scrivere solo tre elementi (titolo, lista e un paragrafo) di un ipotetico documento web il primo listato utilizza undici righe di codice mentre il secondo solo sette. Questo è l’errore tipico commesso dagli editor visuali, i quali riempiono il codice di un documento web di molti elementi assolutamente inutili.

Con questo esempio abbiamo dimostrato che non sempre quindi scrivere codice valido è sinonimo di scrivere buon codice.

É sempre necessario superare la validazione?

Partendo dal presupposto che per uno sviluppatore riuscire a validare il codice che realizza è di solito una soddisfazione personale oltre che una sfida con se stesso, è sempre necessario superare la validazione?

Quel segno di spunta verde che indica un codice validato è generato da un software in conformità al risultato fornito da un algoritmo sviluppato per verificare la correttezza del codice da esaminare. Considerando che un software ha delle regole piuttosto ferree può capitare che il codice di un documento web, seppur sviluppato in modo impeccabile, per una qualsiasi banalità non prevista dall’algoritmo di validazione possa essere non validato.

Facciamo subito un esempio pratico: di default le API di Twitter si basano su di un semplice div – da aggiungere al tuo codice HTML – contenente una lista non ordinata (<ul></ul>) in cui successivamente verranno inseriti i vari tweet caricati tramite una funzione javascript.

<div>
    <ul id="twitter_update_list"></ul>
</div>

Se tentiamo di integrare il nostro account Twitter all’interno di un documento web utilizzando queste API, quando sarà il momento di validare il codice riceveremo un messaggio di errore poiché la lista non ordinata non contiene nessun elemento (<li>…</li>). Anche nel caso in cui avessimo sviluppato l’intero codice del documento web in modo perfetto, questo non sarebbe validato.

Può un errore del genere compromettere la validità dell’intero lavoro che abbiamo realizzato?

Paradossalmente potremmo trovarci in una situazione del genere:

  • un documento web è validato nonostante sia stato sviluppato con grossi problemi di “divite” e “classite” o addirittura impaginato con tabelle;
  • un documento web che – anche se sviluppato in modo impeccabile – con l’integrazione di un elemento di terze parti (come potrebbe essere la Google Maps o il fan box di Facebook, per fare un esempio) si ritrova ad avere un codice non validato.

Quale dei due documenti riterresti più valido?

I casi estremi di validare il codice

Concludo questo articolo con un’ultima riflessione: mi è capitato di vedere qualcuno che nonostante avesse scelto un doctype di tipo Strict per lo sviluppo del proprio documento web poi perdeva ore nel trovare dei metodi alternativi nel tentativo di validare il proprio codice che utilizzava attributi non più consentiti, come per esempio l’attributo target.

Se abbiamo la necessità di utilizzare l’attributo target, perché scegliere un doctype di tipo strict?

Adesso a te la parola: mi piacerebbe sentire il tuo parere sui vari quesiti sollevati nell’ultima parte di questo articolo.

P.s. Il problema dell’API di Twitter è stato riportato solo per fini didattici, in realtà per validare il codice, il problema può essere risolto semplicemente aggiungendo un elemento  della lista contenente uno spazio vuoto: <li> &nbsp;</li>.

Tag: , ,

L'autore

Nando è fondatore di Edi Group, società di Comunicazione e Formazione fondata nel 2005. È inoltre Trainer Microsoft e docente di Webdesign con anni di esperienza, anche in qualità di progettista, in corsi di Formazione Professionale regionali e privati. È stato speaker in diverse prestigiose conferenze, anche per conto di Microsoft Italia. Tiene abitualmente corsi di formazione presso le aziende. È autore di diversi libri sul Web Design, in italiano ed inglese. +

Sito web dell'autore | Altri articoli scritti da

Articoli correlati

Potresti essere interessato anche ai seguenti articoli:

42 commenti

Trackback e pingback

Non ci sono trackback e pingback disponibili per questo articolo