いい感じになってきた。

無精で短気で傲慢なプログラマ | 続・これ、読みやすいの?
最初のソースで解説しておいて、より美しいソースはコレだぜ! という展開 なら納得できますが、最初からリファクタリング後のソースを出すのはどう なんでしょう。小飼さんのソースで編集からの 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