Qual è la migliore pratica per quanto riguarda l'uso di perl-isms (espressioni idiomatiche) in Perl?

Question

Un paio di anni fa ho partecipato alla scrittura delle migliori pratiche/stile di codifica per la nostra azienda (abbastanza grande e spesso in Perl). È stato fatto da un comitato di sviluppatori "senior" di Perl.

Come qualsiasi cosa fatta per consenso, aveva parti in cui tutti erano in disaccordo. Duh.

La parte che si strofinò sbagliato di più è stata una forte raccomandazione di non utilizzare per molti Perlisms (genericamente definito come idiomi codice non presentano, per esempio C++ o Java), come ad esempio "Evitare l'uso di '... a meno che X;' costruisce".

Il razionale principale posto per regole come questa era che gli sviluppatori non Perl avrebbero avuto molto più tempo con il codice Perl altrimenti. L'ipotesi qui è che i perl code jockeys sono di razza più rara nel complesso - e tra i nuovi assunti alla compagnia - rispetto ai non-Perler.

Mi chiedevo se SO abbia qualche argomento valido per supportare o rifiutare questa logica ... è per lo più una curiosità accademica a questo punto poiché lo standard di codifica Perl della società è ossificato e non verrà mai più rivisto per quanto mi riguarda consapevole.

P.S. Giusto per essere chiari, la domanda è nel contesto che ho notato - la risposta per un piccolo negozio di sviluppo tutto-Perl è ovviamente un clamoroso "uso del Perl alla sua massima capacità".

Answer 1

Che tipo di perlismo intendi?

Buono:

• idiomatica per i loop: for(1..5) {} o for(@foo) {}
• scalare la valutazione nell'ambito di array: my $count = @items;
• map, grep e sort: my %foo = map { $_->id => $_ } @objects;

OK se limitata:

• controllo modificatore dichiarazione - trailing se, a meno che, ecc
  • Limitare per l'intercettazione degli errori e ritorna presto. die "Bad juju\n" unless $foo eq 'good juju';
  • Come ha sottolineato Schwern, un altro buon utilizzo è l'assegnazione condizionale dei valori predefiniti: my $foo = shift; $foo = 'blarg' unless defined $foo;. Questo utilizzo è IMO, più pulito di un my $foo = defined $_[0] ? shift : 'blarg';.
  • Motivo da evitare: se è necessario aggiungere ulteriori comportamenti al controllo o ad altro, si ha un grosso lavoro di riformattazione. IMO, la seccatura di ripetere una dichiarazione (anche in un buon editor) è più dirompente rispetto alla digitazione di diversi blocchi "non necessari".
• Prototipi: utilizzare solo per creare funzioni filtrate come map. I prototipi sono accenni al compilatore non "prototipi" nel senso di qualsiasi altra lingua.
• Operatori logici: standardizzare su quando utilizzare and e or rispetto a && e ||. Tutto il tuo codice dovrebbe essere coerente. Migliore se si utilizza una politica Perl :: Critico da applicare.

Evitare:

• variabili locali. L'ambito dinamico è dannatamente strano e lo local non è lo stesso di local altrove.
• Variabili del pacchetto. Abilita cattive pratiche. Se pensi di aver bisogno di uno stato condiviso globale, refactoring. Se è ancora necessario lo stato condiviso globale, utilizzare un singleton.
• Simbolo tavolo hackery

Answer 2

Direi che Moose uccide il 99,9% di Perl-isms, per convenzione, che non deve essere usato: hackery di tabelle di simboli, oggetti di reblessing, violazioni di blackbox comuni: trattamento di oggetti come matrici o hash. La cosa grandiosa è che fa tutto questo senza prendere il colpo di funzionalità di "non usarlo".

Se i "perl-ismi" Sei davvero riferisco sono forma mutatore (mettere in guardia "cattiva idea" a meno che $ good_idea), unless, e until quindi non credo di avere davvero molto più di un argomento, perché questi i "perlismi" non sembrano inibire la leggibilità né perl utenti, né per gli utenti non-perl.

Answer 3

scrivo il codice presupponendo che un programmatore Perl competente sarà leggendo. Non esco dal mio modo di essere intelligente, ma non lo minimizzo neanche.

Se stai scrivendo il codice per le persone che non conoscono la lingua, ti mancherà il più delle volte di usare quella lingua. Spesso scopro che le persone vogliono mettere fuori legge i perlismi perché si rifiutano di imparare più di quanto non sappiano già.

Dal momento che dici di essere in un piccolo negozio Perl, dovrebbe essere piuttosto facile chiedere alla persona che ha scritto il codice cosa significa se non lo capisci. Quel genere di cose dovrebbe venire in recensioni di codice e così via. Tutti continuano a saperne di più sulla lingua in quanto hai periodiche e regolari possibilità di rivedere il codice. Non dovresti lasciare passare troppo tempo senza che gli altri occhi guardino il codice di qualcuno. Certamente non dovresti aspettare fino a una settimana dopo aver lasciato la compagnia.

Per quanto riguarda i nuovi assunti, sono sempre perplesso sul motivo per cui qualcuno penserebbe che dovresti metterli di fronte a una tastiera e girarli allentati aspettando un lavoro produttivo in una base di codice che non hanno mai visto.

Questo non è limitato a Perl. È un problema di programmazione generale. Dovresti sempre imparare di più sui tuoi strumenti. La maggior parte dei grandi negozi che conosco hanno mini-bootcamp per portare gli sviluppatori sulla base di codice, inclusi eventuali bit di codice complicato che possono incontrare.

Answer 4

mi chiedo due semplici domande:

• sto facendo questo perché è diabolicamente intelligente e/o mette in mostra la mia vasta conoscenza di Perl arcani?

Quindi è una cattiva idea. Ma,

• Sto facendo questo perché è Perl idiomatico e beneficia dei distinti vantaggi di Perl?

Quindi è una buona idea.

Non vedo motivi giustificabili per rifiutare, ad esempio, l'interpolazione delle stringhe solo perché Java e C non ce l'hanno.unless è una divertente, ma credo che avendo avviare una subroutine con l'occasionale

return undef unless <something>; 

non è poi così male.

Answer 5

Deve essere stato, come dici tu, qualche anno fa, perché Damian Conway ha 'conquistato il mercato' in standard Perl con Perl Best Practices per gli ultimi anni.

Ho lavorato in un ambiente similmente ossificato, dove non era consentito adottare le best practice più recenti, perché sarebbe una modifica e nessuno a un livello sufficientemente elevato nella struttura aziendale capita (o potrebbe essere preso la briga di capire) Perl e firmare il passaggio al 21 ° secolo.

Una società che distribuisce una tecnologia e la conserva, ma non acquista esperienza o si allena in casa, è chiedendo per problemi.

(direi che si sta lavorando in un ambiente altamente controllato cambiare? - forse finanziaria)

I agree with brian su questo proposito.

Answer 6

Prelevare una copia di Effective Perl Programming: Ways to Write Better, More Idiomatic Perl (2nd Edition) e trattarla come una linea guida. Contiene molti degli idiomi migliori ed è pieno di piccoli frammenti di informazione che ti faranno scrivere un buon codice Perl in stile Perl, al contrario del codice Perl in stile C o Java (o qualsiasi altra cosa).