うっくつさん本を読む。

2011-03-13

とりあえず

はてなポイントを寄付しました。

http://d.hatena.ne.jp/hatenacontrib/20110312/1299904670

2010-03-22

デフォルトって？

ありがちダメなコードのダメな理由を書くコーナー。

char const* getNameFromID(int id) {
  switch (id) {
    case ID_FOO:
      return "FOO";
    case ID_BAA:
      return "BAA";
    default:
      return "TEST";
  }
}

ID_FOOを受け取った場合に"FOO"、ID_BAAを受け取った場合に"BAA"を返すという関数、というところまでは良い(役に立つかどうかは別として)。問題はdefault時に返す"TEST"の存在だ。

まず「正しい動作」を確認しなければならない。このソースコードから逆算すると次の三つくらいはありえるだろう。さて、どれが「正しい動作」なのだろうか。

ID_FOO,ID_BAA以外のときは"TEST"を返す。
ID_FOO, ID_BAA以外のときは未定義。
ID_TESTのときは"TEST"を返す。ID_FOO, ID_BAA, ID_TEST以外のときは未定義。

2010-02-13

ビオラインに見当たらないので。

Web |

From: [781] 名＠無＠し <sage>

Date: 2010/02/13(土) 07:45:41 ID:???

奴ら邪悪ですらないよな。

そしてクリーピングコインが自然界の動物という事実

_________________________________________________

From: [782] 名＠無＠し <sage>

Date: 2010/02/13(土) 09:54:15 ID:???

一応自然金属＋虫って扱いなんだろうか

_________________________________________________

From: [783] 名＠無＠し <sage>

Date: 2010/02/13(土) 12:17:06 ID:???

一見変哲の無いコインを裏返してみたら細かい足がびっしり…とか怖すぎる

_________________________________________________

From: [784] 名＠無＠し <sage>

Date: 2010/02/13(土) 12:27:39 ID:???

コインを背負うヤドカリみたいな生き物を想像した

_________________________________________________

From: [785] 名＠無＠し <sage>

Date: 2010/02/13(土) 15:01:54 ID:???

元ネタがなんなのか知らないけど、Wizに出てきたクリーピングコインはそういう設定だったな。

あるいは甲羅がコインに擬態してるんだったか。どっちでもいいか。

Wizardryの場合、クリーピング・コイン(Creeping Coin?)は魔法生物系で、グラフィックも財宝と同じだったり飛ぶコインだったりする*1。これは明らかに自然界の動物ではない。

しかし、それとは別に上の条件に該当するモンスターがいる。ファミコン版のライノービートルだ。ファミコン版のライノービートルは昆虫系で、グラフィックは背中がまるでコインのような模様になっている。

〆。

ただし、アップル版のライノービートルではただの甲虫だったりする。これは末弥純の独自解釈という可能性も高いな。

*1：得物屋さんを参照。

2010-01-19

それと。

雑記 |

ソフトウェア業界の商用ツールのピンキリ度合はどうにかならないのだろうか*1。価格と性能が比例していないどころか相関すらしていない。まあ、価格と機能数は割合と相関しているかもしれないが、それも価格∝機能数^N, N > 1 というように見える。しかも、自社以外のツールとの連携は一切考えていないというものが多すぎる。

PGReliefは悪くない。けど役にも立たない。

言語, Web |

http://d.hatena.ne.jp/minekoa/20100119/1263914704の話。

あれは最低線を底上げするもの。

PGReliefの指摘観点は公式サイトによると

PGRelief 独自のノウハウでチェック
SECコーディング作法ガイドの適合性チェック
MISRA ルール適合性をチェック（オプション）

となっている。

で、富士通独自ノウハウはまあアレだし、SECコーディングガイドはC言語用だし、MISRAは「難しい機能を使わせない」という発想だし。基本的に、文法を理解していない人が行いがちな失敗を予防する、という程度のものだと思う。

でも、そういった用途ならgccの警告オプションを全開(-Werror -Wall -Wextra -Weffc++ --strict-ansi -pedantic)にした方が有用だ*2。gccやlintの警告なら意味にまで踏み込んだ判定ができるし、attributeやlintコメントによる指定もできる。

〆。

第一、MISRAは「～はドキュメントに記載すること」といった項目の方が重要で、コーディング規約だけMISRA準拠というのはカーゴカルト疑惑が濃厚。

*1：PGReliefの話ではないけれど。

*2：さらに追加オプションを付けるならhttp://d.hatena.ne.jp/higepon/20080430/1209525546を参考に。

2010-01-17

検査例外・非検査例外

言語, Web |

http://d.hatena.ne.jp/kmaebashi/20100114/p1, http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/Nagise/20100116/1263630204の検査例外は重要だけどJavaの検査例外は面倒という話。

文脈が大事。

たとえば、

ユーザ入力の文字列を数値へ変換する。
設定ファイルの文字列を数値へ変換する。

とでは少々扱いが異なる。前者は検査例外を使うべきだろうし、後者は検査例外を使わなくてもよいかもしれない。

その場所で投げられる例外に検査が必要か否かは文脈に大きく依存する。Javaの検査例外が使いにくいのは、文脈に依存した分類ができないから、という面が大きいのではないだろうか。

本来、検査が必要か否かは型から独立して扱うことができるはずだ。lintなどの静的解析ツールではtainted/untaintedという属性を用いてこのような文脈を識別している。

〆。

JavaのAnnotationはこのような文脈識別用途にも利用されている(JSR-305, JSR-308など)が、ライブラリとツールの対応が十分ではなく解析できるはずのものができていない例も多い。これもその一つなのではないかと思う。