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 blocchi di codice ``corti'' 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 abbia scritto - o meno.
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 è stato installato il Perl.
-
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 restituito 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.
-
Provate a documentare il vostro codice e ad usare la formattazione Pod in maniera coerente.
Ecco le convezioni che di solito ci si aspetta:
-
usate
C<> per i nomi di funzioni, variabili e moduli (e più
in generale qualsiasi cosa che può essere considerata parde del codice, come i filehandle
oppure degli specifici valori). Va notato che i nomi delle funzioni sono considerati più
leggibili con le parentesi dopo il nome, cioè come in funzione().
-
usate
B<> per i nomi dei comandi come cat oppure grep.
-
usate
F<> oppure C<> per i nomi dei file. F<> dovrebbe
essere il solo codice Pod per i nomi di file, ma dato che molti formattatori di Pod lo
visualizzano in corsivo, i path di Unix e Windows con i loro slash e backslash
[barre e barre inverse, NdT] possono essere meno leggibili e meglio riprodotti con C<>.
-
Siate coerenti.
-
Comportatevi bene.
La versione su cui si basa questa traduzione è ottenibile con:
perl -MPOD2::IT -e print_pod perlsytle
Per maggiori informazioni sul progetto di traduzione in italiano si veda
http://pod2it.sourceforge.net/ .
Traduzione a cura di Aldo ``dada'' Calpini.
Revisione a cura di dree.
Mon Jun 11 22:02:18 2012
|
