2006年04月24日 00:50 [Edit]

perl - even more best practices

いい感じになってきた。

無精で短気で傲慢なプログラマ | 続・これ、読みやすいの?
最初のソースで解説しておいて、より美しいソースはコレだぜ! という展開 なら納得できますが、最初からリファクタリング後のソースを出すのはどう なんでしょう。小飼さんのソースで編集からの OK が出ますか? (わたしは 雑誌執筆経験がないので、純粋な疑問です)
naoyaのはてなダイアリー - 勝手に添削 - WEB+DB Press Vol.32 オレオレコード版
おうそうか、ということで短期で傲慢なおれもきてみました。いっちょここらでオレオレコードに仕立てあげてみようじゃないか、ということでグループ日記の方にもちょっと書いたけど解説つきでお送りします。

まず、私のサンプルは、実際に雑誌に掲載することを視野に入れている。それが最も顕著に表れているのが、コードの長さ。実物を手に取って見てもらえばおわかりいただけるのだが、本当に狭いのである。残念ながら、そこでのbest practiceはbest productionではない。most conciseということになる。もちろんgolfをしては行き過ぎになるのだけれども。

その意味で、雑誌に書き切れなかったことをWebで補完するというのは、雑誌にとっても著者にとっても、なにより読者にとってよいことだろうと考える。ハテナオヤのMVC版はとても紙面におさまり切れないが、Webであればそういう制限はないのだから。

無精で短気で傲慢なプログラマ | 続・これ、読みやすいの?
途中で return できるのは別に perl 独自の機能ではないですよね。「perl なら許される」ということであれば、ちょっと理解できない。どんな言語で あろうと、基本は出口はひとつがベストと考えます。

さすればlispかscheme、かつletなどは反則として禁じるということになるだろう。「出口は一つ」がベストというのはよく聞く言葉なのだけど根拠がよくわからない。

以下は、search_result()を、「出口が一つ」になるように書き直したものであるが、一つ重大なバグがある。おわかりになるだろうか。

sub search_result{
    my $q = shift;
    if ($q->param("query")){
        my $uri = URI->new($WEBAPI_BASEURL);
        $uri->query_form( appid => $MYYDN_APPID,
                          query => $q->param("query"),
                          results => $MAX_RESULTS );
        my $response = LWP::Simple::get($uri);
        if ($response){
            my $xml = XML::Simple->new->XMLin($response,
                                              ForceArray=>['Result']);
            my @result = ($xml->{'totalResultsAvailable'},  "hits");
            push @result, "<ol>";
            for my $r ( @{ $xml->{'Result'} } ){
                push
                    @result,
                    encode_utf8(sprintf qq(<li><a href="%s">%s</a></li>),
                                $r->{'ClickUrl'}, $r->{'Title'});
            }
            push @result, "</ol>";
            return @result;
        }
    }
}
「この関数は何をしてるの?」という問いに対して、「〜です」とスパッと答えることができない。だから結果的に return に無理が出てくる。

関数名自身がその答えになっている。そして、空のreturnはlist contextであれば()を返す。答えがなければ空リストというのは、print()の引数たる文字列のリストを返すという点で、この場合きちんと首尾一貫しているのだ。

で、わたしが一番気になるのは、雑誌の読者がこのソースを理解できるの? ということです。まぁ、はてなユーザが相手なら問題ないのかもしれませんが、 たとえばラクダ本の存在すら知らなくて、CGI&Perlポケットリファレンス で全部済ませてしまう人も多いわけです。

それで済ませているひとに、それで済ませているのはまずいのだよ、と暗に知らせるのもこうした雑誌の役目だと思うのだけど。ちなみに雑誌などにコードを掲載する場合の優先順位は、

  1. きちんと動く事
  2. 規定のページ数に収まること

であり、その点においてはオリジナルは合格ではあるのだ。この二つ、とくに二つ目をクリアーしているのはオリジナルと私のRefactor版だけなのだ。

小飼さんのソースで編集からの OK が出ますか? (わたしは 雑誌執筆経験がないので、純粋な疑問です)

出る。というより基本的に雑誌はコードの査読をしてはくれない。コードに責任をもつのはあくまで執筆者だ。

だからこそ、コードを書くものの審美眼が問われるのだ。

これだけ世の中にただのソースコードがあふれている昨今、この審美眼というのは、紙媒体に書くにあたってますます重要になってくる。重要なのは初心者にわかりやすいことでは実はない。初心者に、なぜこの人はこういう風に書いたのかということを考えさせ、初心者にちょっと背伸びをさせるコードなのだ。

その意味でも、「無精で短気で傲慢なプログラマ」さんのソースは、傲慢さが足りない。初心者に迎合しすぎているのだ。parse_args()の先祖帰りぶりはいかがなものだろう。MethodをGETからPOSTに変えたとたんにアウトではないか。タグのハードコードぶりはどうであろうか?<ol>からtableに変えたいといった時にどうするのだろうか?しかも、今回は無精さまで損ねている。何と行数も全体の分量も倍になっているのだから。

その意味では、やはりハテナオヤのオレぶりの方が読者にもアピールするし実地で役にも立つ。ただし、雑誌には掲載できないのだけれども。だてにPerl Medicsの監訳をしてたわけではない。とはいえ、ノミ一匹退治するのにバルサンをたくようなゴーカイさではあるが。

とはいえ、「無精で短気で傲慢なプログラマ」さんの短気さは素敵だ。無精、短気、傲慢の中で、成長過程において最も大事なのは短気さかも知れない。その短気さを大事にしてほしい。ただし傲慢と無精でそれを練るのも忘れずに。

finalventの日記 - コーディングというのは職人技なので
ここにこっそり共感。

共感より反感の方が、職人の成長にはいいかも。

Dan the Lazy, Impatient, Hubristic


この記事へのトラックバックURL

この記事へのトラックバック
自分用の備忘録。 Perlのソースコードの書き方のお勉強に。 一連の議論はこの順番に読むとよい。 404 Blog Not Found:perl - 勝手に添削 - WEB DB Press Vol.32 pp.94無精で短気で傲慢なプログラマ | これ、読みやすいの?404 Blog Not Found:perl - There\'s more than on...
Perlの書き方のお勉強に【ブログが続かないわけ】at 2006年04月24日 22:36
コードをあーだこーだと書き換える遊びがはやっているっぽい。 それ Rails R...
PHP5【眠る開発屋blog】at 2006年04月24日 21:28
それPlaggerでもできるよ - module: Subscription::YahooJ config: results: 10 keyword: - plagger - dankogai - naoya Plagger::Plugin::Subscription::YahooJとYahooJ::Searchを入れてね。 YahooJ::Searchのref1:YappoLogs: YahooJ::Search - Yahoo!デベロッパーネットワ...
WEB+DB Press Vol.32のやつって、それPlaggerでもできるよ【YappoLogs】at 2006年04月24日 20:10
まだ買ってない/読んでないんだけど、目的が Yahoo! Web API の解説なら CGI にする必要なくね? ウェブアプリ周りは群雄割拠だしさぁ、好きなの使わせてさぁ。 URL の組み立ては URI ライブラリを使うのがフォーマルなのかな?と思ったが、余計なことに気を取られる感じ...
[ruby] それ Rails Ruby でもできるよ【ξ;゜??゜)ξ { 遅レス。】at 2006年04月24日 15:48
なかなか面白いことになっていますね。 WEB+DB PRESS vol.32って、確か今日発売で元記事は確認していないけど。 ちなみに雑誌などにコードを掲載する場合の優先順位は、 1. きちんと動く事 2. 規定のページ数に収まること これって、出版社&書く人の都合ですね...
[dev]「404 Blog Not Found:perl - even more best practices」【日記という名のチラシの裏】at 2006年04月24日 08:26
本筋とは全然関係ないですが、danさんのコードでは出口がふたつですよね。 http://blog.livedoor.jp/dankogai/archives/50467961.html ほんとの出口ひとつコードはこんなんですよ。 んで、 「出口は一つ」がベストというのはよく聞く言葉なのだけど根拠がよくわから...
それじゃひとつになっとりませんがな【Charsbar::Note】at 2006年04月24日 06:43
この記事へのコメント
出口はひとつに、つって、使わんかもしれん変数宣言を必ず通す、とかってのはそれこそ人間のためだけだと思うけれども。。。
初心者対象のコードが冗長でなければならない理由もよくわからない。
楽譜だって初心者のために長ったらしく書きなおしたものがあるわけではないからね。そんなことしてたら後々その表現から抜け出せない。わからない表現があれば、それよりシンプルな曲で学習するんです。
Posted by gwoooooooo at 2012年12月09日 14:06
return if($flag);
これって将来的にもifが何かを返したりはありえないのでしょうか?
非常に不安なので私はこのような書き方はしません。
#そのような言語は私は知りませんが。
#もしもifが(elseも含めて)成功したかとかを返し始めたらこのようなコードは破綻するんじゃないだろうか。
#return if($flag) $respons;
#とかが待ち受けているだけか・・・

ついでに書くと、この本は初心者は対象にしていないんですよね?
真に初心者が対象であれば、本のページ数が増えようと、コード量が増えても本望だと思いますよ。
例え値段が跳ね上がっても真に参考になるものであれば、経験者もお勧めしやすくて良いのではないでしょうか。(貸し借りとかであっても、初心者が見れれば全然違うかと)
そのような本が出来ないことを非常に残念に思います。

#あ、もしかして本で儲けようとしていらっしゃる?
Posted by Porch at 2006年08月18日 10:08
スクリプトの書き方に正解はなくて、その書き手の理想像が正解になると思う。
なので相手を「傲慢」「短気」などとけなしているのはどうかと思いました!
名前にその言葉が入っていても関係ないと思います。

実際に雑誌に載せるのは編集者さんなので、本当のところを編集者さんから聞いてみたい。

なんか渋谷から東京に行きたい時に
A:複雑だけど早いから地下鉄乗り継いで行く
→最短、乗り換えに迷う可能性
B:1本載るだけの山手線で行く
→Aより5分ほどかかる、簡単

という流れでBはだめなんだよ、社会的に。と言ってる感じににてる。
Bのよさがあるからいいじゃねーか。
目的は同じだし、目的が達成されていれば手段はそれほど気にしなくていいのでは。。。。
Posted by nige at 2006年04月25日 11:38
相談:
ぼくの入り口はひとつですが、出口は肛門と尿道のふたつです。ひとつのほうがいいのでしょうか。

回答:
職人としては美しくありませんね。尿道を肛門にまとめるよう、ブラックジャック先生に頼んでリファクタリングしてもらってください。なお術後は精液も肛門から出るようになりますので、事前にパートナーの方を「このほうがモジュール化されるんだよ!」と説得しておきましょう。
Posted by boguspokesman at 2006年04月24日 09:24