17

perldoc perlsubによると:

& は、サブルーチンが事前に宣言されている場合の括弧と同様に、最新の Perl ではオプションです。

多くの場合、Perl サブルーチンを呼び出すときに括弧を省略できるという事実を人々が使用していることに気付きました (たとえば、最近の SO 回答からランダムに引用します)。

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

と同じくらい有効です

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

2 番目の (括弧なし) バージョンを使用する主な (理想的には技術的な) 理由は何ですか?

perldoc perlsynは、このトピックについて、再びオプション性について言及する以外には何も述べていません。

私にとって、常に括弧を使用することは、私の起源が C 開発者であるため、ほとんどスタイル上の選択です。しかし、Perl 開発者としてオプションの括弧なし構文を使用しないことで何かが欠けているかどうかを知りたいです。

PS私は、括弧付きのバージョンを好む理由をよく知っています-例えば、間接的なオブジェクト表記の問題、または括弧なしで使用される前に非組み込み関数を宣言する必要がある、またはvisavior対の優先順位の問題など||です。逆に興味があります。

PPS私は、意見を裏付ける研究なしに、単に「スタイルが良い」/「読みやすい」と述べている回答にはあまり興味がありません。私は、括弧の省略を好む技術的な理由、またはバックアップされた文体の違いの好みのいずれかに興味があります（「バックアップされた」を「権威に訴える」または「大衆的な議論」の誤謬と混同しないでください。速度または「Perl コミュニティの誰もが同意する」または「Damien Conway がこれを提案する」ではなく、Damien がこれをどのように裏付けているかを説明していません)。

4

4 に答える 4

7

括弧を省略する技術的な理由はありません。それは純粋に好みのコーディング スタイルの問題です。

于 2013-04-02T21:22:24.800 に答える
3

これは純粋にスタイルの問題です。Perl プログラマーにとってはprint "Hi!\n";、print("Hi!\n");. コードをできる限り読みやすくするのは良いスタイルですが、他の条件がすべて同じであれば、シンボルを追加すると読みにくくなります。ビルトインは括弧を必要としないので、それらが提供する曖昧さの解消が追加の認知的負荷を正当化するかどうかを尋ねることは理にかなっています. そして、クラスとしての Perl プログラマーは、ダミアン・コンウェイによる規則の形式化に部分的に助けられて、「いいえ」の側に落ちてきました。

Conway はまた、組み込み関数を括弧なしに保つことがユーザー定義関数との区別に役立つと示唆していますが、私はその議論はあまり説得力がないと考えています。多くのビルトインは括弧なしで自然に読み取れるように設計されているため、そのように使用する必要があると言うほうが正しいです。見defined($x)たりlen($y)、Perl プログラマーをひきつらせたりしますが、見ているだけcroak($z)です。

Perl を C であるかのように書くことは、非常に悪いスタイルであることに注意してください。Perl を Perl であるかのように記述します。

于 2013-04-03T16:31:48.603 に答える