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;