Qual è il motivo per utilizzare le chiamate di subroutine tra parentesi in Perl?

Question

Secondo perldoc perlsub:

Il & è opzionale in Perl moderno, come lo sono parentesi se la subroutine è stata predichiarata.

Ho notato che un sacco di volte, la gente usa il fatto che è possibile omettere la parentesi quando si chiama subroutine Perl (per esempio, in modo casuale citando un recente SO rispondere):

open my $fin, '<', $file; 

è altrettanto valida come

open(my $fin, '<', $file); 

Quali sono le principali (idealmente, tecnici) motivi per utilizzare la seconda versione (tra parentesi-meno)?

perldoc perlsyn non dice nulla sull'argomento oltre a menzionare nuovamente l'opzione.

Per me, usare sempre la parentesi è principalmente una scelta stilistica a causa delle mie origini come sviluppatore C; ma Mi piacerebbe sapere se mi manca qualcosa su non usare la sintassi opzionale senza parentesi come sviluppatore Perl.

---

P.S. Conosco bene i motivi per preferire la versione con parentesi - ad es. the issues with indirect object notation o requirement to declare non-builtins before they are used without parenthesis o problemi con precedenza visavi or vs ||. Mi interessa l'opposto.

---

P.P.S. Non sono molto interessato alle risposte affermando semplicemente "è meglio lo stile"/"più leggibile" senza studi che supportino l'opinione. Sono interessato a motivi tecnici per preferire l'omissione di parentesi, oppure backup preferenze di differenza stilistica (per favore non confondere "backup" con "appello all'autorità" o errori "argumentum ad populum". Uno studio che mostra il miglioramento della velocità o della comprensione di il codice è la prova. "Tutti nella comunità di Perl sono d'accordo" o "Damien Conway suggerisce questo" senza spiegare come Damien non lo supporta).

Answer 1

penso che l'unica volta che in realtà conta, diverso stile, è per l'usato raramente &subname che secondo perldoc perlsub:

&NAME;  # Makes current @_ visible to called subroutine. 

Naturalmente, utilizzando parens potrebbe rendere più agevole disambiguazione in alcuni casi (sia per il parser che per il futuro lettore), oppure non usarli potrebbe rimuovere il rumore in altri; il grado in cui uno di questi è necessario è probabilmente la ragione principale per cui sceglierei l'uno o l'altro.

Answer 2

Da Perl::Critic::Policy::CodeLayout::ProhibitParensWithBuiltins:

Conway suggerisce che tutte le funzioni built-in, senza essere chiamati parentesi che racchiudono la lista degli argomenti. Ciò riduce il disordine visivo e disambigura le funzioni integrate dalle funzioni utente.

Conway è l'autore del Perl Best Practices libro .

Answer 3

Non ci sono motivi tecnici per omettere le parentesi. È puramente una questione di stile di programmazione preferito.

Answer 4

Questa è puramente una domanda di stile. Per un programmatore Perl, print "Hi\n!"; è più leggibile di print("Hi!\n");. È un buon stile rendere il codice il più leggibile possibile e, a parità di tutti gli altri, i simboli aggiuntivi rendono più difficile la lettura. Dal momento che i built-in non hanno bisogno del paren, ha senso chiedersi se la disambiguazione che forniscono giustifica il carico cognitivo aggiuntivo. E i programmatori di Perl come classe sono scesi dalla parte del "no", aiutati in parte dalla formalizzazione della regola di Damien Conway.

Conway suggerisce anche che mantenere i componenti privi di paren-free aiuta a distinguerli dalle funzioni definite dall'utente, ma ritengo che tale argomento sia meno persuasivo. È più corretto dire che molti built-in sono progettati per leggere in modo naturale senza parens, e quindi dovrebbero essere usati in questo modo. Vedere defined($x) o len($y) fa in modo che i programmatori Perl si attivino, ma non più di vedere croak($z).

Si noti che la scrittura di Perl come se fosse C è enfaticamente stile difettoso. Scrivi Perl come se fosse Perl.