Perl - Coding Standard

Ogni programmatore, ovviamente, avrà le sue preferenze riguardo alla formattazione, ma ci sono alcune linee guida generali che renderanno i tuoi programmi più facili da leggere, capire e mantenere.

La cosa più importante è eseguire i programmi sempre sotto il flag -w. Puoi disattivarlo esplicitamente per particolari porzioni di codice tramite il pragma no warnings o la variabile $ ^ W se necessario. Dovresti anche eseguire sempre in use strict o conoscere il motivo per cui no. Anche l'uso di sigtrap e persino di utilizzare pragmi diagnostici può rivelarsi utile.

Per quanto riguarda l'estetica del layout del codice, l'unica cosa a cui Larry tiene fortemente è che la parentesi graffa di chiusura di un BLOCCO multilinea deve allinearsi con la parola chiave che ha iniziato il costrutto. Oltre a ciò, ha altre preferenze che non sono così forti -

  • Rientro a 4 colonne.
  • Se possibile, aprire ricci sulla stessa riga della parola chiave, altrimenti allineare.
  • Spazio prima del ricciolo di apertura di un BLOCCO multilinea.
  • BLOCCO di una riga può essere messo su una riga, inclusi i ricci.
  • Nessuno spazio prima del punto e virgola.
  • Punto e virgola omesso in BLOCCO "breve" di una riga.
  • Spazio intorno alla maggior parte degli operatori.
  • Spazio attorno a un pedice "complesso" (tra parentesi).
  • Linee vuote tra blocchi che fanno cose diverse.
  • Altri non coccolati.
  • Nessuno spazio tra il nome della funzione e la sua parentesi di apertura.
  • Spazio dopo ogni virgola.
  • Linee lunghe interrotte dopo un operatore (tranne e e o).
  • Spazio dopo l'ultima parentesi corrispondente sulla riga corrente.
  • Allinea verticalmente gli elementi corrispondenti.
  • Ometti la punteggiatura ridondante finché la chiarezza non ne risente.

Ecco alcune altre questioni di stile più sostanziali su cui riflettere: solo perché PUOI fare qualcosa in un modo particolare non significa che DOVRESTI farlo in quel modo. Perl è progettato per darti diversi modi per fare qualsiasi cosa, quindi considera di scegliere quello più leggibile. Ad esempio:

open(FOO,$foo) || die "Can't open $foo: $!";

È meglio di -

die "Can't open $foo: $!" unless open(FOO,$foo);

Perché il secondo modo nasconde il punto principale dell'istruzione in un modificatore. D'altra parte,

print "Starting analysis\n" if $verbose;

È meglio di -

$verbose && print "Starting analysis\n";

Perché il punto principale non è se l'utente ha digitato -v o meno.

Non passare attraverso stupide contorsioni per uscire da un ciclo in alto o in basso, quando Perl fornisce l'ultimo operatore in modo da poter uscire nel mezzo. Basta "ridurlo" un po 'per renderlo più visibile -

LINE:
for (;;) {
   statements;
   last LINE if $foo;
   next LINE if /^#/;
   statements;
}

Vediamo alcuni punti più importanti:

  • Non aver paura di usare le etichette di loop: sono lì per migliorare la leggibilità e per consentire interruzioni di loop multilivello. Vedi l'esempio precedente.

  • Evita di usare grep () (o map ()) o `backtick` in un contesto void, cioè quando butti via i loro valori di ritorno. Queste funzioni hanno tutte valori di ritorno, quindi usale. Altrimenti usa un ciclo foreach () o la funzione system ().

  • Per la portabilità, quando si utilizzano funzionalità che potrebbero non essere implementate su ogni macchina, testare il costrutto in una valutazione per vedere se fallisce. Se sai quale versione o livello di patch è stata implementata una particolare funzionalità, puoi provare $] ($ PERL_VERSION in inglese) per vedere se sarà presente. Il modulo Config vi permetterà anche di interrogare i valori determinati dal programma Configure al momento dell'installazione di Perl.

  • Scegli identificatori mnemonici. Se non ricordi cosa significa mnemonico, hai un problema.

  • Sebbene gli identificatori brevi come $ gotit siano probabilmente ok, usa i trattini bassi per separare le parole in identificatori più lunghi. In genere è più facile leggere $ var_names_like_this rispetto a $ VarNamesLikeThis, soprattutto per i non madrelingua inglese. È anche una semplice regola che funziona in modo coerente con VAR_NAMES_LIKE_THIS.

  • I nomi dei pacchetti a volte sono un'eccezione a questa regola. Perl informalmente riserva nomi di moduli in minuscolo per moduli "pragma" come integer e strict. Altri moduli dovrebbero iniziare con una lettera maiuscola e utilizzare maiuscole e minuscole, ma probabilmente senza trattini bassi a causa delle limitazioni nelle rappresentazioni dei nomi dei moduli dei file system primitivi come file che devono rientrare in pochi byte sparsi.

  • Se hai un'espressione regolare davvero pelosa, usa il modificatore / x e inserisci degli spazi bianchi per far sembrare un po 'meno il rumore di linea. Non utilizzare la barra come delimitatore quando la tua espressione regolare ha barre o backslash.

  • Controlla sempre i codici di ritorno delle chiamate di sistema. I buoni messaggi di errore dovrebbero andare a STDERR, includere quale programma ha causato il problema, quali erano la chiamata di sistema fallita e gli argomenti e (MOLTO IMPORTANTE) dovrebbe contenere il messaggio di errore di sistema standard per cosa è andato storto. Ecco un esempio semplice ma sufficiente:

opendir(D, $dir) or die "can't opendir $dir: $!";

  • Pensa alla riutilizzabilità. Perché sprecare le capacità intellettuali in un one-shot quando potresti voler fare di nuovo qualcosa del genere? Considera l'idea di generalizzare il tuo codice. Considera l'idea di scrivere un modulo o una classe di oggetti. Considera l'idea di eseguire il codice in modo pulito con use strict e use warnings (o -w) in vigore. Considera l'idea di regalare il tuo codice. Considera l'idea di cambiare la tua visione del mondo. Considera ... oh, non importa.

  • Sii coerente.

  • Sii gentile.