たれぱんのびぼーろく

わたしの備忘録、生物学とプログラミングが多いかも

入力に対する制約

一般に入力バリデーションと呼ばれるもの。

対象は関数からフォームまで色々広く

プログラムは (明示的・暗示的に) 入力に想定範囲を持つ

プログラムを書く際、入力には範囲が想定されている。
argAは文字列だとか、英数字だけだとか、intだとか、非ゼロだとか.
指定していなくても、関数内のコードでは入力はこの辺りだと暗示的に考えながら書いていることが多い.
想定外の領域が正しい振る舞いをするか否かは、神のみぞ知る (保証されない).
正しく振る舞って欲しいのなら、入力は想定範囲内に収められていなければならない。

入力に制約を設けるメリット

想定範囲外の入力が引き起こす正しくない振る舞いが原理上起きなくなる.

セキュリティの観点から見れば、安全が確保されやすくなる。
good codingの観点からみれば、codingの大半を占めるDebugが減る.
behavior driven developmentの観点からみれば、関数の定義域が明確になるので振る舞い設計が明確になる.
テストの観点からみれば、テスト範囲が限定されるのでテスト作成不可が減り実質のカバレッジも上がる.

入力に対する制約の実現方法

  • 型: ざくっりした入力の制約
    • 入力組み合わせに対する制約は型で記述するのが手間 (な気がする)
  • 入力バリデーション: 完全に記述が可能

強く関連するトピック

  • セキュアプログラミング(防衛的プログラミング): 安全性の観点から。セキュアプログラミングの一方法論としての入力バリデーション
  • DbC, 契約プログラミング: バグ抑制の観点から

word

疑問点

静的に評価できるのか?
関数をpipeしているときにpipeの出入力で範囲がミスマッチ起こしていないか確認できないか?

実用

JS

  1. まず型を導入してみる (TypeScript etc)
  2. 関数の頭にasset入れて端から検証 (ドキュメンテーションがつらみ)
  3. DbC補助ライブラリの導入

qiita.com

# DbCで入出力をきっちりして、きっちりして…?
動的バリデーションをずっとかけておけば、バグった時にちゃんとassertはしてくれる。
全モジュールで入出力バリデーションしとけば、安全。

独自型を書くのと何が違うのだろうか.

依存型

myuon.github.io

オブジェクト型にして、validationかけておけば事実上は制限付き型に出来はする

型とvalidationを比べてメリットデメリット

documentation: 型のほうが色々充実しているイメージ