Effective C# 6.0/7.0 項目1 について
この内容については初めてコードレビューを行ったときに、会社で仕事ができると言われていた先輩から
「ローカル変数の型名はvarで良くない？」
と指摘があった。
実はこの時、varについては凄く調べていて、その結果ローカル変数でも型名はしっかりと名前を付けるようにしていた。
理由としては「場合によっては、型が分かりづらくなるから」という文言を目にしたためだ。
もちろん、Variant型との違いは理解した上での話である。
で、結果指摘が入ったがそのとき先輩は
「最近はコードをできる限り書かないようにコーディングしている」
言い換えれば書くのが面倒だから使っている、という旨を話していた。
他に意図があるかもしれないが、そのときは「できる限りコードを減らすことも、確かに重要かな」と感じ、納得した。
その日を境にvarを使い続けています。
Contents
乱用すると保守性が著しく低下する
varは基本的には便利だと思います。
ただし、これはコード全体で見た時に不備が少ない場合に限ります。
不備が少ない、という言葉が大分曖昧ですが、例えば以下の2つでは可読性に大きな差があります。
result1は型名が全く推測できませんが、result2に関してはメソッド名のおかげで何となくbool型であることが推測されます。
(初めてGistを導入したので上手いコードが書けずすみません)
何が言いたいかと言えば、varを使用する上で一番重要な事は「ローカル変数名又はメソッド名又はその両方に適切な命名をすること」です。
これに関しては型推論についての是非以前の問題な気もしますが、重要な事ですよね…。
最近は特に「どういった命名が、可読性、保守性、美しいコードになるか」という事を必死に考えていたので凄く身にしみます。
型推論の話は命名法と命名意識の問題と結び付けて考えるのが良さそうですね。
仕事上、doubleをよく使うことがあるのですが組込み型は初期化を明示し忘れる事が多いのでその辺も注意が必要です(varをdoubleで推論させたい場合は、0で初期化するときに0.0と書く必要がある)。
開発者よりも最適な型推論をする場合もある
この辺はLINQとQueryの話で、普段の業務的にはあまり使わない内容なので、使用した際に更新します…。
つまみだけ話すと、クエリを書くときにIEnumerableなどの型で宣言してしまうと、IQueryable側の同名メソッドを呼び出したかったのにも関わらず、(派生元の)IEnumerableのメソッドが呼び出されて、結果が全く変わってしまう、といった内容です(たぶん)。
“常に”ではなく”なるべく”型推論を利用する
最後にこのように書かれています。
コードを理解するために型の宣言が必要にならないのであれば、varが最善である。
数値型などは型を明記することを推奨する。
これに尽きると思います。
何でもかんでもvar,var,varで書いてきましたが、必要性を考えて使う必要があると理解しました。
今後はもっと頭を働かせてコードを書きたいと思います。
命名もできる限り意味論的情報が分かるよう、心掛けたいと思います。
コメント