La guida di brian
http://www.perl.it/documenti/articoli/2008/07/la-guida-di-bri.html
© Perl Mongers Italia. Tutti i diritti riservati.


NOME

La guida di brian per la risoluzione di qualsiasi problema sul Perl

RIASSUNTO

Seguite questa guida e evitate di impazzire

DESCRIZIONE

La mia filosofia di debugging

Io credo in tre cose:

Non è una cosa personale

Dimenticati la proprietà del codice. Puoi pensare a te stesso come ad un artista, ma anche i grandi Maestri hanno prodotto un sacco di schifezze. Il codice di chiunque è una schifezza, il che significa che il mio codice è una schifezza e il tuo codice è una schifezza. Impara ad apprezzare questo fatto. Quando hai un problema, il tuo primo pensiero dovrebbe essere "C'è qualcosa che non va nel mio schifoso codice". Questo significa che non devi prendertela con perl. Non è una cosa personale.
Scordati di come tu fai le cose. Se il tuo modo di fare le cose funzionasse, non staresti qui a leggere. Non è neppure una brutta cosa: è semplicemente tempo di progredire. Ci siamo passati tutti.

Responsabilità personale

Se hai un problema con il tuo script, è proprio questo: un tuo problema. Dovresti fare tutto il possibile per risolverlo da solo. Ricorda, ognuno ha i propri script, il che significa che ognuno ha i propri problemi. Svolgi i tuoi compiti per casa e fai del tuo meglio prima di dare fastidio a qualcun altro con i tuoi problemi. Se hai davvero provato tutto quello che è scritto in questa guida e non riesci ancora a risolvere il problema, hai fatto del tuo meglio ed è ora di dare fastidio a qualcun altro.

Cambia il modo in cui fai le cose

Risolvi le cose in modo da non avere di nuovo lo stesso problema. Il problema sta probabilmente in come scrivi il codice, non in cosa scrivi. Cambia il modo in cui fai le cose, in modo da semplificati la vita. Non forzare Perl ad adattarsi a te stesso, perché non si adatterà. Adattati tu a Perl. È solo un linguaggio, non uno stile di vita.

Il mio metodo

Il tuo script compila usando i controlli sintattici?

Se non stai ancora usando i controlli sintattici, attivali. I guru del Perl sono tali perché usano strict, che lascia loro molto più tempo per risolvere altri problemi, imparare cose nuove e inserire moduli funzionanti in CPAN.
Puoi attivare i controlli sintattici all'interno del codice con la direttiva strict.
        use strict;

Da linea di comando, puoi attivare i controlli sintattici con il parametro -M a perl.
        perl -Mstrict script.pl

Potresti essere infastidito dai controlli sintattici, ma dopo un paio di settimane di programmazione con i controlli attivi, scriverai del codice migliore, perderai meno tempo a rincorrere dei semplici errori, e probabilmente non avrai bisogno di questa guida.

Cosa sono gli avvertimenti?

Perl può darti un sacco di avvertimenti sui costrutti discutibili. Attiva gli avvertimenti e lascia che Perl ti aiuti.
Puoi usare il parametro -w nella shebang.
        #!/usr/bin/perl -w

Puoi attivare gli avvertimenti dalla linea di comando.
        perl -w script.pl

Puoi usare gli avvertimenti lessicali con tutta una serie di caratteristiche interessanti. Dai un'occhiata a warnings per i dettagli.
        use warnings;

Se non capisci un avvertimento, puoi cercarne una versione esplicativa in perldiag, oppure puoi usare la direttiva diagnostics nel codice.
        use diagnostics;

Risolvi il primo problema per primo!

Dopo aver ottenuto da perl un errore o un messaggio di avvertimento, risolvi il primo messaggio e poi vedi se perl continua a lamentarsi. Gli ulteriori messaggi potrebbero essere stati conseguenze del primo problema.

Guarda il codice prima del numero di linea nel messaggio d'errore!

perl ti fornisce dei messaggi d'avvertimento nel momento in cui inizia a preoccuparsi, non prima. Al momento in cui perl è preoccupato, il problema è già capitato e il numero di linea di cui perl si sta occupando sta in realtà dopo il problema. Dai un'occhiata un paio di espressioni prima del numero di linea dell'avvertimento.

Il valore è quello che tu pensi che sia?

Non tirare ad indovinare! Esamina davvero il valore, subito prima di usarlo in una espressione. Il migliore debugger dell'universo è print.
        print STDERR "Il valore e` [$valore]\n";

Ho racchiuso $valore tra parentesi in maniera da poter vedere eventuali spazi o a capo all'inizio o alla fine del valore.
Se ho a che fare con qualcosa di diverso da uno scalare, uso Data::Dumper per stampare le strutture dati.
        require Data::Dumper;

        print STDERR "L'hash e` ", Data::Dumper::Dumper( %hash ), "\n";

Se il valore non è quello che pensi sia, torna indietro di qualche passo e prova di nuovo! Fai così fino a che non trovi il punto nel quale il valore smette di essere quello che pensi dovrebbe essere!
Puoi anche usare il debugger integrato in perl, tramite il parametro -d. Studia perldebug per i dettagli.
        perl -d script.pl

Puoi anche utilizzare altri debugger o ambienti di sviluppo, come ptkdb (un debugger grafico basato su Tk) oppure Komodo (l'IDE Perl di Activestate basato su Mozilla).

Stai usando la funzione in maniera corretta?

Programmo in Perl da un sacco di tempo e consulto ancora perlfunc quasi tutti i giorni. Alcune cose non riesco proprio a memorizzarle, e qualche volta ho così tanto sonno arretrato che il cervello se ne va in vacanza, e mi domando come mai sprintf() non stampi a schermo.
Puoi cercare una particolare funzione con il comando perldoc e il suo parametro -f.
        perldoc -f nome_funzione

Se stai usando un modulo, controlla la documentazione per assicurarti di usarlo nel modo giusto. Puoi controllare la documentazione del modulo usando perldoc.
        perldoc Nome::Modulo

Stai usando la variabile speciale giusta?

Di nuovo, io faccio continuamente riferimento a perlvar. Beh, non proprio, visto che trovo The Perl Pocket Reference molto più facile da usare.

Hai la versione giusta del modulo?

Alcuni moduli cambiano il loro comportamento da una versione all'altra. Hai la versione del modulo che pensi di avere? Puoi controllare la versione della maggior parte dei moduli con una semplice riga di perl.
        perl -MNome::Modulo -le 'print Nome::Modulo->VERSION';

Se consulti la maggior parte della tua documentazione sul web, ad esempio su http://www.perldoc.com oppure http://search.cpan.org, invece che leggere quella che hai sulla tua macchina, è più facile che tu finisca per leggere la documentazione di una versione diversa da quella che hai.

Hai scritto dei piccoli test?

Se stai sperimentando qualcosa di nuovo, o se pensi che una particolare porzione di codice si stia comportando in maniera bizzarra, scrivi il programma più breve possibile che implementi quella porzione e nient'altro. Questo toglie di mezzo la maggior parte dei fattori irrilevanti. Se questo breve programma di test fa quello che pensi debba fare, probabilmente il problema non sta in quel codice. Se il programma non fa quello che pensi debba fare, forse hai trovato il problema.

Hai controllato l'ambiente?

Alcune cose dipendono dalle variabili d'ambiente. Sei sicuro che siano impostate con i valori giusti? Il tuo ambiente è lo stesso che il programma vede quando è in esecuzione? Ricordati che i programmi eseguiti via CGI o cron, possono vedere ambienti differenti rispetto a quelli eseguiti nella tua shell, specialmente su altre macchine.
Perl mette a disposizione l'ambiente tramite %ENV. Se hai bisogno di una di queste variabili, fornisci un valore di default per quando non esiste, anche solo a scopo di test.
Se hai ancora qualche problema, esamina l'ambiente.
        require Data::Dumper;
        print STDERR Data::Dumper::Dumper( \%ENV );

Hai controllato Google?

Se hai un problema, probabilmente qualcun altro l'ha già avuto. Controlla se qualcuno ha già pubblicato qualcosa su usenet nel gruppo comp.lang.perl.misc, tramite la ricerca con Google Groups (http://groups.google.com/). La differenza tra le persone che fanno domande su usenet e quelle che rispondono, sta nell'abilità di usare Google Groups.

Hai misurato le prestazioni della tua applicazione?

Se vuoi scovare le parti lente del programma, ne hai misurato le prestazioni? Fai fare il lavoro pesante a Devel::SmallProf. Devel::SmallProf conta le volte che perl esegue ciascuna linea di codice e quanto impiega ad eseguirla, e stampa un bel resoconto.

Quale test fallisce?

Se hai una suite di test, qual'è il test che fallisce? Dovresti essere in grado di scovare l'errore molto velocemente, visto che ogni test dovrebbe esercitare solo una piccola porzione di codice.
Se non hai una suite di test, perché non farne una? Se hai uno script davvero breve o si tratta di un uno script usa e getta, non ti obbligo certo a scrivere un paio di test. In tutti gli altri casi, un po' di script di test portano molti vantaggi. Test::Harness rende l'esecuzione dei test talmente semplice, che non hai proprio alcuna scusa per non scriverli. Se non ne hai il tempo, forse stai sprecando troppo tempo nel fare il debug degli script senza i test. MakeMaker e simili non sono solo per i moduli, si possono usare anche per gli script.

Hai parlato con l'orsacchiotto?

Spiega il tuo problema ad alta voce. Pronuncia davvero le parole.
Per un paio d'anni ho avuto il piacere di lavorare con un programmatore davvero bravo che riusciva a risolvere praticamente qualsiasi cosa. Quando ero proprio bloccato, andavo alla sua scrivania e iniziavo a spiegare il problema. Di solito non arrivavo alla terza frase senza dire "Lascia perdere, ho capito". Non si sbagliava quasi mai.
Visto che ti capiterà piuttosto spesso, ti consiglio di procurarti un qualche peluche che ti faccia da "psicanalista" Perl, in modo da non disturbare i tuoi colleghi. Io ho un orsetto seduto sulla mia scrivania, al quale spiego i miei problemi. La mia ragazza non fa neppure più caso a quando parlo da solo.

Il problema sembra differente sulla carta?

Stai guardando fisso il monitor del computer; magari un supporto differente ti farà vedere le cose in un una maniera diversa. Prova a dare un'occhiata ad una stampa del tuo programma.

Hai guardato il quiz quotidiano con Gerri Scotti?

Davvero. Se non vi piace Gerri Scotti, sceglietevi qualcos'altro. Fate una pausa. Smettete di pensare al problema per un po' e lasciate che la vostra mente si rilassi. Torna al problema più tardi, e la sua risoluzione potrebbe essere immediatamente ovvia.

Hai cestinato il tuo ego?

Se, arrivati a questo punto, non hai ancora risolto, il problema potrebbe essere psicologico. Potresti essere emotivamente legato ad una certa parte del codice, per cui non vuoi cambiarlo. Potresti anche pensare che tutti abbiano torto tranne te. Ogni volta che pensi qualcosa del genere, non stai prendendo seriamente in considerazione la più probabile fonte di bug -- tu stesso. Non ignorare nulla. Verifica tutto.


AUTORE

brian d foy, <bdfoy@cpan.org>

TRADUZIONE

Traduzione a cura del gruppo di www.perl.it Originale disponibile presso http://www.pair.com/~comdog/brian's_guide.pod

COPYRIGHT

Copyright 2002, Perl Documentation Project, Tutti i diritti riservati