my @c= map {
my $v=$_;
map {$_ * $v } @m
} @a;
このように使用map
するのは良い習慣ですか?なぜだめですか?そうでない場合、他の方法は何ですか?
my @c= map {
my $v=$_;
map {$_ * $v } @m
} @a;
このように使用map
するのは良い習慣ですか?なぜだめですか?そうでない場合、他の方法は何ですか?
それが良い習慣かどうかは答えられません。一般に、ネストされたマップを頻繁に使用する状況はたくさんあります。短く、簡潔で要領を得ています。
ただし、このようなネストされたマップは、常にわずかに大きくなりすぎて扱いにくくなる危険性があります。その場合、必要以上に読みにくくなります(どのリストが$_
その場合に参照されますか!?)。ですから、それらを使用してください、はい、しかし注意して使用してください-Perlをとても簡潔で表現力豊かにする他のすべての同様のものと同じように。
どういう意味かわかりません。それは完全にうまく機能しますか、それとも読みやすさについて質問していますか?map
同等のforeachループと比較して、longを読み取るのは難しい場合があります。
my @c;
for my $v (@a) {
push @c, map { $_ * $v } @m;
}
私はいつもmap
コマンドで複雑な気持ちを持っていました。を使用する際の落とし穴はたくさんありますがmap
、それはPythonの人々がPerlがどれほど読めないかをうっとりさせるものの1つです。その上、map
通常のループを使用するよりも実際にはそれほど効率的ではありません。
mapがの値を変更するとき、$_
それは実際には元の配列の値の単なるエイリアスであるため、落とし穴があります。を変更$_
すると、元の配列が変更されます。たぶんそれはあなたが望むものですが、map
コマンドはそれを覆い隠すことができます。PerlMonksでについての議論がありmap
ます。
map
内での使用がmap
実際に機能する場合でも(map
ローカライズさ$_
れるため、$_
一方は他方map
と同じではありません)、読みやすさと保守性の問題があります。$_
map
使用map
法が明確で、文脈を理解しやすい場合にのみ使用してください。電子メール信号用の巧妙なPerlトリックを保存します。map-within-mapは使用しません。
Nestedmap
には、再割り当ての必要性によってわずかに増幅されることを除いて、他のネストされた構造と同じ問題と同じ解決策があり$_
ます。ネストされたmap
ものも流れないという事実は、コードの臭いです。コードは、少し異なる構造にする必要があることを伝えようとしています。
そして、適切な変更は、リーダーが両方のスコープを同時に追跡する必要がないように、内部操作を関数呼び出しにすることです。その場合、次のようになります。
sub scale {
my ($factor, @numbers) = @_;
return map { $factor * $_ } @numbers;
}
my @c = map { scale($_, @m) } @a;