ビューティフルコード

Essay プログラミング オライリー Comments

ビューティフルコード
タイトル
ビューティフルコード
著者
Brian Kernighan (著), Jon Bentley (著), まつもとゆきひろ (著), Andy Oram (編集), Greg Wilson (編集), 久野 禎子 (翻訳), 久野 靖 (翻訳)
出版社
オライリージャパン
Amazonで購入する

本書は、ブライアン・カーニハンをはじめ一流のプログラマが各々の考える「美しいコード」を紹介するエッセイです。

世界屈指の一流ハッカーがこれぞ！と思うコードを読むことができる貴重な一冊です。

名前付け、アルゴリズム、アーキテクチャ、ショートコードなどなど美しいコードとして紹介されているものは様々です。また、言語も様々なため、知らない言語のコードは美しさがよくわからないところもあるかもしれません。

それでも、30人を越える偉人が紹介する ビューティフルコード は、プログラミング好きにはたまらないと思います。

おぼえがき

美しいコードの第一歩

美しいプログラムを書く第一歩は、 だいたい正しく動くコードを書くところ から始まります。エラー処理や例外処理を除いたほとんどの場合に正しく動く。そこから美しいコードは生み出されます。

美しいプログラムは、やさしい条件を先に扱って、難しい条件を後に書きます。

デザイナーが自分は完璧に達成したんだと分かるのは、付け加えるべきものが何もない時ではなく、取り去るべきものが何もない時である。

Jon Bentley が自分が書いた一番美しいコードとして紹介しているクイックソートのコードです。

quicksort.c
1
2
3
4
5
6
7
8
9
10
11
12
13

void quicksort(int l, int u)
{
    int i, m;
    if (l >= u) return;
    swap(l, randint(l, u));
    m = l;
    for (i = l+1; i <= u; i++)
        if (x[i] < x[l])
            swap(++m, i);
    swap(l, m);
    quicksort(l, m-1);
    quicksort(m+1, u);
}

プログラミングは実用的なスキルだと信じており、「実用的なスキルは、真似をすることと練習することで獲得する」

プログラムの速度

正しく、美しく、速く。プログラムはこの順番であるべきです。クヌース先生は言いました。「未熟な段階での最適化は、プログラミングに置ける諸悪の根源」であると。

正しく動くコードを書いて、O(N2) の場合には O(logN) に落とす。できれば O(N) にしたいところですが。正しいコードを美しくすることで、速度が改善されることが往々にしてあります。

フレームワーク設計

フレームワークの設計で一番の難題は、API をいったん公開したら、公開 API の仕様を変更したり、インターフェースを変えたりすることが難しくなることです。

この問題に対応するための伝統的な方法が次のものになります。

  1. public とするものは公開範囲を小さく保つ
  2. インターフェースを使い、できるだけ実装だけでは公開しない
  3. 拡張を意図する場所は「フック」を良く考えて用意しておく
  4. 拡張が起こってほしくない場所は拡張できないようにする

JavaMail の例です。

1
2
3
4
5
6
7
8
9

package javax.mail;

public final class Session {
    ...
    public static Session getDefaultInstance(Properties props);
    ...
    public Store getStore() throws NoSuchProviderException;
    ...
}

1
2
3
4
5

public abstract class Store extends javax.mail.Service {
    ...
    public void addStoreListener(StoreListener listener);
    ...
}

ビューティフル・テスト

テストを美しくする3つの手法。

簡潔さゆえに美しいと言えるテスト
数行のテストコードで対象コードの基本的な動作を文章化したり検証できる。短いコードで端的に動作を説明できているので美しい。
コードの優雅さ、保守性、テストしやすさを増す方法が分かるために美しいと言えるテスト
コードをもっと美しくするのを助けてくれるようなテストのこと。プログラムの論理的な問題点、構造の問題、設計上の問題に気付く助けになるようなテストは美しい。
幅と深さゆえに美しいと言えるテスト
基本的なケースや厳選したケースだけでなく、すべてのケースにおいてコードが期待通りに動くという自信を持たせてくれるようなテストコードは美しい。

大きなビットマップ画像を扱う処理

縦px×横px×深さの3重ループで処理するのは論外。フィルタロジックをハードコード刷るよりも良い方法は、ビットマップの大きさ、ピクセルの深さ、フィルタの大きさと要素の値に応じて、その場でカスタムコードを生成すること。

（うーむ、ちょっとここはいまいち理解が出来ませんでした。。本書を読んで自分で理解してください。。）

ネットワーク

インターネットを使えば通信線でつながったハッカー達は世界中どこからでも仕事ができる。なんて言われているけど、そんなことを吹聴している奴らはカリフォルニアのごく狭い場所に集まっている。

エンドユーザ向けのアプリケーションでは、使いやすさが極めて重要です。また、スタートダッシュの為には、まず 動くプロトタイプで本質部分を作って そこから製品レベルに持っていくのは常によいアイデア。

システムをできる限りシンプルに保つことは常に偉大なアイデアです。ソフトウェアは なまもの なので、常に注意し、更新し、機能追加し、修正し、調整し、サポートする必要があります。

感想

美しいコードの基準は人それぞれですが、共通してい言えることは 正しく動く、ムダな部分がない、高速に動作する ものだと思いました。

プログラミングのエッセイだと、やっぱりアルゴリズム系の話題が多いので、ソースコードの見た目が美しいとかいうのはあまりなく、設計思想や短いコードにいろいろな意味が込められているようなものを美しいと感じる偉人が多いようでした。

簡単な問題から解く。正しさが疑いようのないくらいシンプルにコードを保つ。そういうのが大事だと改めて感じました。

ある程度広くコンピュータの知識がある人は、本書を読むと「なるほど」となる場面が多いと思います。

関連記事