NOME

perlstyle - Guida allo stile Perl

DESCRIZIONE

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.

TRADUZIONE

Versione

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/ .

Traduttore

Traduzione a cura di Aldo "dada" Calpini.

Revisore

Revisione a cura di dree.