perlstyle - Guida allo stile Perl
Ogni programmatore avrà, ovviamente, le sue preferenze riguardo alla
formattazione, ma qui ci sono alcune linee guida generali che renderanno i
vostri programmi più facili da leggere, capire e manutenere.
La cosa più importante è che i programmi vengano sempre fatti girare
con il flag -w. Può essere disabilitato esplicitamente
per particolari porzioni di codice con la direttiva no
warnings o la variabile $^W se proprio è necessario.
Dovreste anche scrivere sempre con use strict o essere ben
coscienti delle ragioni per cui non lo state facendo. Anche le direttive
use sigtrap e use diagnostics possono rivelarsi
utili.
Riguardo all'estetica del codice, l'unica cosa che davvero importa a
Larry è che la graffa finale di un blocco di codice su più righe sia
allineata con la parola chiave che ha aperto il costrutto. A parte questo,
lui ha altre preferenze ma non sono così fondamentali.
- Rientri di 4 spazi.
- Parentesi graffa aperta sulla stessa linea della parola chiave,
possibilmente, altrimenti allineata verticalmente.
- Uno spazio prima della graffa aperta di un blocco di codice su più
righe.
- Blocchi di codice di una riga sola possono stare tutti sulla riga,
incluse le graffe.
- Nessuno spazio prima del punto e virgola.
- Punto e virgola omesso in ``corti'' blocchi di codice da una riga.
- Spazi intorno a quasi tutti gli operatori.
- Spazio intorno ad una subscript ``complessa'' (all'interno di
parentesi graffe).
- Linee vuote fra pezzi di codice che fanno cose diverse.
else su una riga a parte.
- Nessuno spazio tra il nome della funzione e la sua parentesi aperta.
- Uno spazio dopo ogni virgola.
- Linee lunghe spezzate dopo un operatore (eccetto per ``and'' e
``or'').
- Uno spazio dopo l'ultima parentesi chiusa corrispondente alla prima
aperta sulla riga corrente
- Allineare verticalmente cose simili fra loro.
- Omettere la punteggiatura ridondante fintanto che la chiarezza non
ne risente.
Larry ha le sue ragioni per ognuna di queste cose, ma non pretende che
il cervello di tutti gli altri lavori come il suo.
Qui ci sono altre questioni più sostanziali su cui riflettere:
- Solo perché POTETE fare qualcosa in un certo modo non vuol
dire che DOVRESTE farlo in quel modo. Il Perl è progettato in
modo da darvi numerosi modi di fare qualunque cosa, quindi pensate a
scegliere quello più leggibile. Ad esempio
open(PIPPO,$pippo) || die "Impossibile aprire $pippo: $!";
è meglio di die "Impossibile aprire $pippo: $!" unless open(PIPPO,$pippo);
perché il secondo modo nasconde il punto principale dell'istruzione
con un modificatore. D'altra parte print "Avvio analisi\n" if $verboso;
è meglio di $verboso && print "Avvio analisi\n";
perché il punto principale non è se l'utente ha scritto
- o no.
Inoltre, solo perché un operatore vi lascia sottintendere degli
argomenti di default, non vuol dire che dovete utilizzare i default. I
default sono lì per i programmatori pigri che stanno scrivendo programmi
``usa e getta''. Se volete che il vostro programma sia leggibile,
fareste meglio ad esplicitare gli argomenti.
Sulla stessa lunghezza d'onda, solo perché POTETE omettere
le parentesi in molti casi, non vuol dire che lo dobbiate fare: return print reverse sort num values %array;
return print(reverse(sort num (values(%array))));
Quando siete in dubbio, mettete le parentesi. Se non altro
consentiranno a qualche balordo di giocare con il tasto % in
vi.
Anche se non siete in dubbio, considerate la sanità mentale della
persona che dovrà manutenere il codice dopo di voi, e che probabilmente
metterà le parentesi nel posto sbagliato.
- Non fate inutili contorsioni per uscire da un ciclo all'inizio o
alla fine, quando il Perl ha l'operatore
last che permette
di uscirne anche a metà. Solo, rendetelo un po' più visibile diminuendo
il rientro da destra. LINEA:
for (;;) {
istruzioni;
last LINEA if $foo;
next LINEA if /^#/;
istruzioni;
}
- Non temete di usare delle etichette per i cicli, sono lì per
migliorare la leggibilità oltre che per consentire l'uscita da cicli
annidati. Vedete l'esempio precedente.
- Evitate di usare
grep() (o map()) o le
`backticks` in contesto vuoto, ossia quando scartate ciò che
restituiscono. Queste funzioni hanno dei valori resituiti, quindi
utilizzateli. Altrimenti usate un ciclo foreach() o la
chiamata system().
- Per mantenere la portabilità, quando utilizzate funzionalità che
potrebbero non essere implementate su macchine diverse, racchiudete il
costrutto in un eval per vedere se fallisce. Se sapete già che una
particolare funzionalità è stata implementata in una versione del Perl,
potete controllare
$] ($PERL_VERSION usando
English) per verificare che ci sia. Il modulo
Config inoltre vi dà la possibilità di interrogare i valori
determinati dal programma Configure quando il Perl è
stato installato.
- Scegliete identificatori mnemonici. Se non vi ricordate cosa vuol
dire mnemonico, avete un grosso problema.
- Anche se identificatori corti come $sonoqui sono ok, utilizzate i
trattini bassi per separare le parole. È generalmente più facile leggere
$nomi_come_questi che $NomiComeQuesti, specialmente per chi non parla il
vostro stesso linguaggio. È anche una semplice regola che è coerente con
NOMI_COME_QUESTI.
I nomi dei package sono spesso un'eccezione a questa regola. Il Perl
si riserva informalmente i nomi di modulo in minuscolo per le direttive
come integer e strict. Gli altri moduli
dovrebbero iniziare con una lettera maiuscola e utilizzare
MaiuscoleAdInizioParola, possibilmente senza trattini bassi per via di
limitazioni in file system primitivi che devono rappresentare il nome
del modulo come nome di file che deve entrare in una manciata di
byte.
- Potreste trovare utile utilizzare le maiuscole o minuscole per
indicare lo scope o la natura di una variabile. Ad esempio:
$TUTTO_MAIUSCOLO solo costanti (attenzione ai conflitti con le variabili perl!)
$Qualche_Maiuscola globali/statiche in un package
$tutto_minuscolo variabili di funzione my() o local()
I nomi di funzioni e metodi sembrano andare meglio tutti in
minuscolo. Ad es. $obj->as_string().
Potete utilizzare un trattino basso iniziale per indicare che una
variabile o funzione non dovrebbe essere utilizzata al di fuori del
package che l'ha definita.
- Se avete un'espressione regolare molto complicata, utilizzate il
modificatore
/x e metteteci un po' di spazi per farla
assomigliare un po' meno a una sequenza insensata di caratteri. Non
utilizzate la barra (/) come delimitatore se la vostra
espressione regolare contiene barre o backslash.
- Utilizzate i nuovi operatori ``and'' e ``or'' per evitare un po' di
parentesi, e per ridurre l'incidenza della punteggiatura di operatori
come
&& e ||. Chiamate le vostre
subroutine come se fossero funzioni od operatori di lista per evitare
eccessive ``e commerciali'' e parentesi.
- Usate gli ``here documents'' [
print <<FINE, NdT]
invece di ripetere tante istruzioni print().
- Allineate verticalmente cose simili fra loro, specialmente se sono
in ogni caso troppo lunghe per stare su una riga.
$IDX = $ST_MTIME;
$IDX = $ST_ATIME if $opt_u;
$IDX = $ST_CTIME if $opt_c;
$IDX = $ST_SIZE if $opt_s; mkdir $dirtmp, 0700 or die "errore in mkdir $dirtmp: $!";
chdir($dirtmp) or die "errore in chdir $dirtmp: $!";
mkdir 'tmp', 0777 or die "errore in mkdir $dirtmp/tmp: $!";
- Controllate sempre il valore restituito dalle chiamate di sistema.
Dei buoni messaggi di errore dovrebbero andare su STDERR, includere il
nome del programma che ha causato il problema, la chiamata di sistema
fallita ed i suoi argomenti, e (MOLTO IMPORTANTE) dovrebbe contenere
l'errore standard ritornato dal sistema operativo per capire cosa non è
andato bene. Di seguito un esempio molto semplice ma sufficientemente
esplicativo:
opendir(D, $dir) or die "errore in opendir $dir: $!";
- Allineate le traslitterazioni quando ha senso:
tr [abc]
[xyz];
- Pensate alla riutilizzabilità. Perché buttar via risorse su un
programma ``usa e getta'' quando potreste voler fare qualcosa di simile
un'altra volta in futuro? Considerate la possibilità di generalizzare il
vostro codice. Valutate se scrivere un modulo o una classe di oggetti.
Pensate a far girare bene il vostro codice con
use strict e
use warnings (o -w). Considerate la
possibilità di rilasciare ad altri il vostro codice. Considerate la
possibilità di cambiare interamente la vostra visione del mondo.
Considerate... beh, lasciamo stare.
- Siate coerenti.
- Comportatevi bene.
Mon Oct 24 04:01:56 2005 |
