静的な型チェックを強化する - 命名規則の活用

間違ったコードが間違って見えるコーディング規則を探すこと。
Joel Spolsky
プログラミングにおける変数や関数、クラス設計の命名というのは、そのプログラムの可読性を左右する最も重要な要素のひとつです。変数名や関数名が適切であれば、プログラムの流れも読みやすいですし、バグがあっても見つけやすいものです。
さて、このような命名規則(命名規約)といったものは、大抵それ読む人間のために設定されます。コンパイラにとっては、変数名がoldUserNameだろうがounだろうがxだろうが、関係ありません。変数名は単なる記号です。

しかし、考えて見るとこれは非常にもったいない。人間が、変数名からエラーを発見できるということは、このルールを(広い意味での)コンパイラに教えてあげれば、同じようにエラーを発見してもらえるのではないでしょうか。

例えば以前に次のようなバグコードを見たことがあります。
  ....
  len = strlen(name);
  strncpy(buf, name, sizeof(len));
  ....
ひとめで何がおかしいか分かるでしょうか。答えは、strncpyにsizeof(len)を渡しているのが間違い。sizeof(buf)のような与え方をすることも多いので、うっかり間違えたのでしょう。このようなコードは人間がよく見ればわかりますが、コンパイラにとっては何が間違いかはわかりません。C言語上の型チェックとしては、どちらもsize_tが渡るので問題ないと解釈されてしまいます。よって、この問題をコンパイラがコンパイル時に(静的に)発見することはできません。

ということで対策案。上の例でいえば、いたって単純な方法が考えられます。まず、lengthのようなものをsizeofでサイズ取得するというのは、あまりなさそうです。よって、sizeof(len.*)というパターンをソースでgrepしてみると。ものすごくピンポイントな対応ですが、このパターンでみつけられバグは結構ありそうに思います。

4894716860 ようは、命名規則がきまっていれば、単なる記号論理だけでなく、意味論までふみこんだ静的解析ができるんじゃなかろうかと。アプリケーションハンガリアンと呼ばれる変数の意味的な側面に注目してプレフィックス等の命名ルール呼ばれる命名規則を決める手法(参考:間違ったコードは間違って見えるようにする - Joel on Software)がありますが、これも人間に臭うコードが見えるようにするというだけではもったいない。ある程度ルールを決めれば、コンパイル時点でCPUに検出させることもできるのではないかと思うのです。

例えば、次のようなものもうまくやれば検出できそうです。
/* database中のoldをnewに置き換え */
void replace(DB* db, const char* old, const char* new);
...
  replace(db, new, old);
  ....
プロトタイプでは、newもoldも同じ型ですが、プロトタイプの変数名を見ればold->newの順番だとわかります。ところが、通常のコンパイラでは、上のようにnewとoldがいれかわっていても検出することはできません。おそらく人間でも直感的には間違いに気が付きにくいと思いますが、これもせっかくの仮引数名を利用してやれば、何とか検出できそうです。

意味論の解釈というのは難しいとはいえ、発想自体は単純な話ではあるので、すでにいろいろツールありそうに思って探したのですが、見つかりません。CheckStyleのような命名規則をチェックしてくれるものがあるので、これをカスタマイズすればできるのでしょうか。単なる規約以上は無理なのか・・

ご存知の方おられたらぜひ教えてください m(_ _)m。

【関連記事】
変数の命名規則
テキストとしてのコーディング規約
コンパイル時の静的チェック(STATIC_ASSERT)
【関連書籍】
Joel on Software Joel Spolsky 青木 靖
組込みソフトウェア開発向けコーディング作法ガイド[C言語版] SEC
C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス ハーブ・サッター他
リファクタリング―プログラムの体質改善テクニック
プログラミング作法

【関連リンク】
間違ったコードは間違って見えるようにする - Joel on Software
ハンガリアン記法 - 悪態のプログラマ

誰にとっての最適化? - Gコードの場合

デザインはわがまま→思いやり
川崎和男 『ドリームデザイナー

最近はユニバーサルデザイン(UD)という言葉を良く耳にするようになりました。はてなキーワードの説明では、『ユニバーサル=普遍的な、全体の、という言葉が示しているように、「すべての人のためのデザイン」を意味し、年齢や障害の有無などにかかわらず、最初からできるだけ多くの人が利用可能であるようにデザインすること。』となってます。つまり、全ての人にやさしいデザインということになるでしょうか。
この「ユニバーサル」つまり「全ての人に」という部分は非常に重要な考え方だと思いますが、やはり人によって得手不得手がありますので、ものによっては、どうしてもこっちを立てればこっちがたたずといった状態になります。こうなると、どこを立てるか、つまり、どんな評価関数でもって最適化をかけるかということが重要になります。

さて、こんなことを書いているのは最近Gコードの構成についてなるほどーっと思ったのがきっかけです。

Gコードといえばテレビ番組の予約等で使われる数桁の数字。新聞のラテ欄やTV雑誌でおなじみですね。といっても、最近は、EPG搭載のデジタルTVやDVD/HDDレコーダが普及して、あまり使われなくなった感がありますが。さて、Gコード、原理的には、数文字の数字に、番組の開始・終了日時、チャンネル情報を符号化したものになっています。ですので、この数字を対応のVHSビデオやDVDレコーダに入力すると、これら予約録画に必要な情報に変換して、予約録画ができるという仕組みです。

はてさて、このあたりまでは使われたことがある方ならご存知かもしれないのですが、今回私がなるほどと思ったのは、この数字の符号化方法にあります。Gコードの数字列は可変長コードになっているのですが、この数字列、ゴールデンタイムの番組、つまり視聴率の高そうな番組程短くなるように符号化されているのです。いわゆる、エントロピー符号化というやつです。時には、一文字のこともあるそうです(※1)。知ってました?
つまり、Gコードの符号化設計における評価関数はユーザーの予約頻度なんですね。

478850362X で、ここでふと思ったのは、「では、今のGコードの符号化って本当に使われ方に対して最適化されているの?」ということ。実際の仕様は公開されていませんが、個人で解析されている方の情報等をみると、結構こったことになっているようですが、そもそもいろんな趣向を持った人がいるのに、最適化ってどうするのだろうという疑問。
まず単純に考えると、時間帯や番組長、チャンネル等で予約頻度順に符号長も短くなるようにするという方法。つまり、世の中の全予約の平均長を短くするという方針。単純に考えるとこうなるのでしょう。多分Gコードもそういう考え方がもとになっているのだと思います。
しかし、よく考えれば、Gコードを使う人って機会慣れした若者から不慣れなおじいちゃん、おばあちゃんまでいろいろおられるはず。となると、「各番組の予約頻度」×「その番組の視聴者層の機械慣れ具合」といった重み付け後の値でもって最適化を考えないといけないのかとかも考えられます。
いやいや、そもそも機械慣れしているなら少々数字が多くても大丈夫だから、この層は一旦おいておいて、おじいちゃん・おばあちゃん層の番組の最適化を進めるというのもひとつの考え方としてあるだろうとか。。
考え出すとこれがなかなか奥が深い。

プログラミング時には、アルゴリズムの性能指針として、平均オーダーと最悪オーダーが使われます。平均と最悪、どちらが特に重要かは、ユースケースによってかわってきます。この考え方は、ユーザビリティを考える時もこれは同じ。先の例では、全番組予約頻度で符号化長を調整するのは平均値の最適化。おじいちゃん・おばあちゃん優先で最適化するのが最悪値の最適化といえなくもないでしょう。
自分自身ふりかえると、大抵の設計時には、ついつい平均値優先になっていたなぁという気がします。きっと、その方がわかりやすいからでしょう。

冒頭の「デザインはわがまま→思いやり」というのは、デザインディレクター 川崎和男氏の言葉。『考具―考えるための道具、持っていますか?』という本の中で紹介されていたので知ったのですが、とても大好きな言葉です。ユーザビリティは、単純に数学的に最適化できるものではありません。最後のまごころ忘れちゃいけませんね。

※1 2005年6月1日放送のNHKきょうの料理では、一部新聞でGコードが「1」と掲載されたため、同番組の出演者が珍しく「当番組をぜひ見てほしい」と宣伝した事もあるんだそう。

【関連書籍】
誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書) ドナルド・A. ノーマン
ユーザビリティエンジニアリング原論―ユーザーのためのインタフェースデザイン ヤコブ・ニールセン
アフォーダンス-新しい認知の理論 佐々木正人
暗号解読 上巻 (1) (新潮文庫) サイモン・シン 青木 薫

【関連記事】
できることが増えると、できないことが増える
プログラム+インターフェース=モジュール
似て非なるインターフェース
選択できない選択肢

【関連リンク】
Gコード解析(analyzing VCR-plus code)
ユニバーサルデザイン - コクヨ
Webデザイン・Webデザイナーのまとめサイト | Webデザインに優れたサイトのリンク集
ヤコブ・ニールセンの考えをまとめたユーザビリティガイドライン
Jakob Nielsen博士のAlertbox
楽天はデジタル家電の新製品を随時ご紹介

本のおすすめ

4274065979

4844337858

482228493X

4904807057

4873114799


プロフィール

  • Author:proger
  • 組み込み関係で仕事してます

ブログ内検索