アカウント名:
パスワード:
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
他人のコードを読むスキルには、かなり高度なものが必要だと思います。
＃ビール片手に一ヶ月前に書いた自分のコードは(ry
ピンクのらくだ本(Perl4の時代っすね)を一通り理解したロートルなんで大外しかも知れませんがご容赦を。perlスキルは、自分ででかいの書いたことはなくて、フリーのCGIを拾ってきて改造する程度です(^^;;
以下の2点で、やっぱりperlは読みにくいよなぁ、、、と思います。＃ (念のため)Hobby useでの話です。業務ではLL自体使いません
1. 暗黙の参照これのおかげで記述が省略されているところが多いと読み下すのにすごく大変です。＃ 『慣れ』の問題だとは思うんですけど、『慣れるまでが大変』というか、＃ 『慣れる前に放り出したくなる』っていうか(苦笑)
2. やりかたは何通りもあるらくだ本に何度も出てくるフレーズで“perl
私は、条件を満たさなかった場合であることを明示するため、else節を入れる方が良いように思います。このような一行しかなければ明白ですけど、else節となるべき部分が長くなる場合には分かりにくくなると思います。
今回の例の場合、if文の後に処理がありません。わざわざ/* NOT REACHED */と置いていますが、elseを使わない書き方なら構造がそれを示しますから、lintや読者に対する説明が不要になります。
また、今回の例では違うと思いますが、もし真と偽が対等な正常ルートならelse節で書いたほうがわかりやすいでしょう。
あと、いまどきの流儀だと、かなり細かく積極的に関数にくくり出すことが望まれますので、else節が長くなる心配はないです。関数やファイル数が増えるのを嫌う人もいますので、その方法を取れない場合もあるでしょうが。
さらに余談ですが、一時期話題になった「OOコード養成ギブス [hatena.ne.jp]」(邦訳の出た「ThoughtWorksアンソロジー」の一節)では「else禁止」なんてのがあります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
Perlはもっと評価されていい (スコア:0)
難点といえばソースが丸見えなことがビジネス的に問題なくらいで、Javaが目指したクロスプラットフォームは満たしているし、開発者にとって日本語みたいなUNIXシェルや、一番慣れ親しまれている開発言語であるCとの共通点も多いので、Javaほどプログラマに求める新たな開発スキルは必要ない。
現実に組織内で完結する環境では、業務ツール開発言語として最も頻繁に使われてるように思える。
Re: (スコア:1, 興味深い)
最近のPerlはそうでもない気がします。
Re: (スコア:2, すばらしい洞察)
他人のコードを読むスキルには、かなり高度なものが必要だと思います。
＃ビール片手に一ヶ月前に書いた自分のコードは(ry
Re: (スコア:1)
ピンクのらくだ本(Perl4の時代っすね)を一通り理解したロートルなんで大外
しかも知れませんがご容赦を。
perlスキルは、自分ででかいの書いたことはなくて、フリーのCGIを拾ってき
て改造する程度です(^^;;
以下の2点で、やっぱりperlは読みにくいよなぁ、、、と思います。
＃ (念のため)Hobby useでの話です。業務ではLL自体使いません
1. 暗黙の参照
これのおかげで記述が省略されているところが多いと読み下すのにすごく大変
です。
＃ 『慣れ』の問題だとは思うんですけど、『慣れるまでが大変』というか、
＃ 『慣れる前に放り出したくなる』っていうか(苦笑)
2. やりかたは何通りもある
らくだ本に何度も出てくるフレーズで“perl
♪潔くカッコよく生きてゆこう
Re: (スコア:0)
・then節でreturnしていればelseは不要
・変数に入れてすぐにreturnするなら、直接書く
・ifは例外的なもの(この場合は終了条件かな)を先に書く(条件を逆にしました)
int foo_2a(int x)
{
if (x == 0) {
return 1;
}
return x * foo_2a(x - 1);
}
Re:Perlはもっと評価されていい (スコア:1)
私は、条件を満たさなかった場合であることを明示するため、else節を入れる方が良いように思います。このような一行しかなければ明白ですけど、else節となるべき部分が長くなる場合には分かりにくくなると思います。
Re: (スコア:0)
今回の例の場合、if文の後に処理がありません。わざわざ/* NOT REACHED */と置いていますが、elseを使わない書き方なら構造がそれを示しますから、lintや読者に対する説明が不要になります。
また、今回の例では違うと思いますが、もし真と偽が対等な正常ルートならelse節で書いたほうがわかりやすいでしょう。
あと、いまどきの流儀だと、かなり細かく積極的に関数にくくり出すことが望まれますので、else節が長くなる心配はないです。関数やファイル数が増えるのを嫌う人もいますので、その方法を取れない場合もあるでしょうが。
さらに余談ですが、一時期話題になった「OOコード養成ギブス [hatena.ne.jp]」(邦訳の出た「ThoughtWorksアンソロジー」の一節)では「else禁止」なんてのがあります。