常連

```PHP
/**
* 自然数同士の足し算を行う
*
* @param integer $x 自然数であること
* @param integer $y 自然数であること
* @return integer $xと$yの合計値
*/
function Add($x, $y) {
    $sum = $x + $y;
    return $sum;
}
```


このようなコードがあるとします。
$x, $yが引数として妥当であること（型がintegerである、自然数である）の検査をする箇所について質問があります。
検査すべき場所として下記3パターンあると思うのですがどれが妥当なのですか？
(a)関数内で行うもの
(b)呼び出し側で行うもの
(c)a,b両方で行うもの

防衛的プログラミングや契約プログラミングというワードを「達人プログラマー」の書籍でしり混乱しています...
上記3パターン以外の手法も歓迎しております。どうかお知恵をお貸しください。


【追記】
情報の質と量が多くみなさんの全ての回答を読めていません。
いまだ「未解決」のままになっていますが週末利用して頂いた回答を理解できるように致します。

関数の引数はどこで検査するべきか

自律で動作するロボットを作りたいと考えているのですが
タイトルにあるような事柄を学ぶ必要が出てきました。
そこで質問なのですが、これらを学ぶにあたって有用な書籍やウェブサイトを
教えていただけないでしょうか？
大雑把な質問で申し訳ありません。疑問等ありましたら補足します。

Linuxにおけるプロセス間通信、割り込み、同期などを勉強したい。

階層構造をデータベースに落とし込む際に範囲検索が簡単な
[入れ子集合モデル]を採用しようと思っています。
 
木構造(親node一つのみ)なら
 [入れ子集合モデル]に落とし込むことで検索の高速化を計れると思います。

ですが

セミラティス構造(親nodeを複数持てる)の場合
 [入れ子集合モデル]に落とし込むと複数の親を持つnodeを複製する必要が
 でてきます。結果、システムが複雑になりパフォーマンスが落ちてしまいます。


どなたか複製せずに、セミラティス構造のnode検索を高速化するアルゴリズム、
アイディアをご存知の方がいらっしゃいましたらご教授ください。
特に、[入れ子集合モデル]である必要はございません。

追記:[条件]複数の親を持てるのは葉nodeのみ
追記:使用しているデータベース：MySQL
追記:検索＝親を指定するとその子孫たる葉nodeすべて取得
追記:nodeに対する操作
    親を指定しnode追加➡️必須
    既存のnodeを削除➡️必須
       既存のnode間にnodeを追加➡️必須
    既存のnode間の親子関係を削除➡️必要なし
       既存のnode間に親子関係を追加➡️必要なし

  [問題のところ]
   親を複数指定しnodeを追加➡️追加したnodeは葉nodeで複数の親をもつ葉nodeにnodeは追加できません。

[アルゴリズム][データベース設計]階層構造のデータベース設計

最近開発をしていて思うのはコードリーディングは自分でコード書くより大変な時があります。
なんとなく、自分はコードリーディングが下手なのか、書かれているコードがおかしいのか、大した動作をしていないのに、ものすごくコードを読むのに時間がかかることがあります。

読みやすいコードを書くのは基本ですが、現実は読みにくいコードをなんとか読まなければならない状況の方が多いと思っており,共同開発者やオープンソースコミッターがデザインパターンに沿ってコードを書いていることを期待してはいけなく,最近では無からコードを生成する能力に比して,読みにくいコードでも読める力のウエイトの方が実務では大事なのではないかと思うようになりました。(自分が1から書けば良くなることがわかってる状態だとしても,何がしたいのかをコードから読み取らなければならないことが多いからです)

どうすれば読みにくいコードでも効率良く読み進めることができるか方法を思索しています。
最近ではものすごく時間をかけて調査した結果、些細なバグの原因が全くそのクラスと関係ない場所で定義されたメソッドで副作用起こしてるから等がありました。

特に読みづらいと思ったのは以下のような特徴を持つプロジェクトのコードです。


- moduleと継承が混在していて名前空間で分かれていないメソッドの呼び出し(どのファイルで定義された関数,メソッドなのかがわからない)
- そのスコープにおいて有効な変数が多すぎる(やむを得ない場合もありますが一時変数すらインスタンス変数に設定してあるものなど,インスタンス変数の定義場所と使用場所の区別がつかない場合など)
- 処理の途中で違う処理が挟まってる(単一処理できないこともありますが)
- 継承の多用(概念的に綺麗であれば大丈夫ですが分岐や深過ぎる継承同じ概念でまとめられるはずの継承)
- 大き過ぎるメソッド
- 小さすぎる大量のメソッド(的確に切り分けられてないと定義を飛び続けて元のコードの処理を追いづらくなる)
- 処理フローがめちゃくちゃなメソッド（名前と実行してる処理が違う,名前に対して色んな処理をしすぎ）
- 同じ処理が複数ファイルに散在している(読みづらい上に一箇所の変更が複数ファイルに伝播して直すのも大変)


このような特徴を持つコードでも読む時に意識すると読みやすくなるってことありますか？もしコードリーディングで意識していることがあれば教えて下さい。(ファイル上に存在しないメソッドは継承,標準ライブラリ,mixinで的を絞るなど)

よろしくお願いします。

コードを読みやすくするために意識していることを教えてください。

いつも本当に助かっています。
テーブルの設計についてご意見をお聞かせください。

仕事でデータロガーのシステムというものを実装しました。
そのシステムは外部の機械から何らかのデータを受けとり、保存していくだけの単純なものですが、受け取るデータ構造を可変としています。

---

例：
- 機械Ａは 気温、湿度、気圧
- 機械Ｂは 電圧、電流
- これらのデータが各機械から１０秒毎に（23℃, 30%, 1000hPa というように）送信されるので受信し保存する。


条件：
- 機械毎のデータ定義を画面から設定する。
(何カラムあり、どのカラムが何のデータで、型は何で、有効桁数が何桁で、単位は何か、等）
- 各カラムのデータ型は真偽値、整数値、小数値、文字列がある。
- 機械Ａも機械Ｂも数千台程度接続されている。今後機械Ｃも追加される
- データを元に各機械毎のグラフを描画したり全体で集計したりする。閾値判定も行う。
- データ蓄積後、定義の変更はある程度許容する。（列の追加や単位の変更など）

---

これらを実現するためのテーブル構造の案として、下段に記載した幾つかの案などがあるかと思います。
実はもうこのシステムは「案１」で開発が終了し、問題なく稼働しています。
上記は例ですが、実際に数億レコードのデータが蓄積されています。
ただ、設計実装が私一人で周りに頼れる人もなく、設計に不安があるため、皆様のご意見をお聞かせください。

**質問１．情報が少なくて恐縮ですが、「案１」を採用したのは正解だと思いますか？
質問２．現実的な案として下段以外のものはありますか？
質問３．下段の案の中で、上記条件に対して「ありえない」と考えるものはありますか？
質問４．一般的にこういったもののデザインパターンはありますか？
質問５．他、経験談や参考情報などありましたらご教示ください。**


実際に問題なく稼働しているのだからいいじゃん、という部分もあるかと思いますが、後学のためよろしくお願いいたします。
※できるだけ広くご意見を頂きたいので少し長めに質問をオープンしておくかもしれません。

CentOS7.2, MariaDB10.0, Java8

---

### 案

**１．ID, 機械ID, キー(VARCHAR), 値(VARCHAR), 日時 のカラムを持つテーブルを用意する。**
  ※一旦値をVARCHARで保存し(小数値1.23ならそのままテキストで)、読み出し時に各定義の型に合わせて解釈します。
  ※１カラム（例えば気温）だけで１レコード消費します。
  ※閾値判定時、VARCHARカラムに対して平気で 「値 > 1.23」 のようなことをやります。
  ※１回の送信データを示す集計基準は機械IDと日時です。
  ※この案を採用しました。


**２．「定義ごとに柔軟にテーブルを作る」システムを作る。**
  ※プログラムが CREATE TABLE 文を発行します。
  ※なんだか気持ち悪いという理由と、システムが複雑化しそうという理由で却下しました。
  ※データ量は最も少なくなり運用も楽そうなため、今はこちらの方がよかったかも、と思っています。


**３．ID, 機械ID, c1, c2, c3, c4..., 日時 のようにカラムを予めたくさん用意し、カラムとデータの対応テーブルを別途用意する。**
  ※ダサく感じたので却下しました。なしではなかったなと思っています。


**４．ID, 機械ID, データ(VARCHAR), 日時のカラムを用意し、データにXML, JSON, ハッシュオブジェクトシリアライズなどで保存する。**
  ※集計と運用が厳しくなるかと思い却下しました。


**５．RDBを用いない。**
  ※RDB以外を知らないことと、集計が厳しくなると思い、却下しました。