インスタンスを使うとき、コンストラクタで生成するのであれば
それ以降のコード内には悪意のある記述でもしないかぎりnullチェックは必要ないかもしれませんが
例えばアプリ内のオブジェクトをFindしようとしたりデータベースからデータ取得をしようとした際に、必ずそこにインスタンスが入っている保証はない。

同様にメソッドのパラメータにインスタンスを指定したり、
配列のインデックスを渡した時にそれがnullではなかったり範囲外ではない、と言い切れる保証はないので（むしろ上位アプリ層はそんなこと意識して作ってはいけない）
ほとんどのメソッドの入口にそのメソッドで扱うデータが有効であるかのチェックをしないと気が済まなくなってしまっています。
とにかく扱う直前にそのインスタンスがnullでないことを確かめないと気が済まないのです。
配列もやっぱり範囲外は怖いのでチェックします。

しかしそうやって書いていくうちにあちこちのメソッドは有効チェックだらけに....
おかげでそのオブジェクトを振り回す側はなにも考えることなく指定のタイミングでメソッドを投げまくれるのでタイトな作りにもなるのですが。。。
C#やJavaなどはある種ポインタだらけといっても過言ではないので、いちいち有効チェックなんてやってられないのかも
不正ならExceptionが投げられるからtry～catchで括るべきなのだろうか。


安全第一ですが、傍から見たらすごく馬鹿らしいことをしているのかもしれない。
C#は結構長く触っていますが、改めてどうすればいいかに悩む今日この頃。

処理の書き方は大体以下のパターンにおさまるかと
1.前処理(宣言、インスタンス生成)
2.引数判定
3.主処理
4.例外処理
5.後処理(インスタンスの破棄など)
このうちのどれかが無いと、何かしら想定外のことが起こるのかなと思っています。
なのでコメントで上記の1.～5.を必ず明記するようにしています。
後処理がないとか該当する処理がない場合とかでは、// NOP (No operation)とでも書いとけば、忘れたことにならないしね

…安全第一でやりすぎということはないと思う今日この頃。　笑

外部から与えられた物は，チェックするのが基本ですね。
.NET 4以降だとCodeContracts + Rewriterという選択肢があるので，便利になっています。
CodeContracts EditorがよくCrashしたり，Rewriterがビルド時間を引き延ばす問題はありますが。

そのあたりの動きも，DbCを言語サポートする方向にありそうです。

> へにっくすさん
＞…安全第一でやりすぎということはないと思う今日この頃。　笑
ですよねー！
安全であることに越したことはないですよね！
そうでありたい、そうであってくれー！

＞YuOさん
私は条件が偽であったらExceptionとBreakを呼ぶような仕組みを使ってチェックしていますね。
CodeContractsの存在は知りませんでしたがUnityなどの環境だとWindows上であれば動きそうな気がするので
試してみる価値がありそうです！
C#ではConditional属性などもあるので、本番環境でハングアップしないように制御できるのが良いですよね。
Cでもマクロを使えばできなくはないですが...