« Delphi/C++Builder 2010 8月25日発売 | メイン | 日本のソフトウェア産業がいつまでもダメな理由 »

プログラム言語における見た目と意味の不一致

BEST SOFTWARE WRITING』を読んで、なるほど、と思った。

C系の言語(C、C++、Java)では、人の目はインデントをブロックkの定義としてみるが、コンパイラの方は{}を見る。
だからインデントと括弧が対応していない場合、人の目にはよりわかりにくいほう──{}──が勝つことになる。
(中略)
なぜ1つの方法にこだわって、コードの見た目と意味が一致するようにしないのか?

BEST SOFTWARE WRITING

インデントのずれによるソースコードの見た目とコンパイラが解約する意味の不一致が、 バグを生み出すことは珍しくありません。

# よくある間違い
if (x > 10)
    y = 0;
    z = 0;

コーディング規約を定めることで、このようなバグを減らそうとする試みが一般的です。

# コーディング規約で{}を強制
if (x > 10) {
    y = 0;
    z = 0;
}

Pythonはインデントを文法に組み入れることによって、見た目と意味を一致させて、効率的なプログラミングを実現しました。
プログラム言語に「ソースコードの見た目」という情報を取り入れたという点で画期的だったのかもしれません。

それから、

何らかのコーディングスタイルが、一般的なスタイルと比べて非常に大きな利点を持つことは、 これまでのところなかったし、これからもないだろう。

BEST SOFTWARE WRITING

というのも、その通り。
ハンガリアン記法という効率の悪いコーディング規約もあるけど。

トラックバック

このエントリーのトラックバックURL:
http://www.gesource.jp/mt/mt-tb.cgi/1036

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2009年08月07日 21:30に投稿されたエントリーのページです。

ひとつ前の投稿は「Delphi/C++Builder 2010 8月25日発売」です。

次の投稿は「日本のソフトウェア産業がいつまでもダメな理由」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type 3.35