リーダブルコード

C#リーダブルコード #09_bool型の判定

前回はbool型の判定方法に関して解説しましたが,今回も,bool型を判定する際の注意点を解説していきます。以前「否定の否定はしない」という感じのことをお伝えしていますが,今回はより詳しく,考えられるパターンを考察したいと思います。

BAD:無駄に否定系にしない:Trueじゃないとき

bool型は前回の解説の通り,bool型の変数単体で判定できるので,次のような書き方をすることはないとは思いますが,想定されるパターンの網羅ということで,こういった書き方はしないでおきましょうという意味で解説します。「!= true」という感じで,「Trueじゃないとき」という書き方は,「Falseの時」と同じ意味なので,無駄に否定形にしないようにしましょう。

「Falseの時」を表現する場合は,次のように書けばOKですね。

BAD:否定の否定にしない1

「!= ture」よりさらに悪い例として,falseとの比較をNOTイコールで行う場合ですね。「!= false」という書き方は,「Falseではない時」というわけで,結局は「Trueの時」ということになるので,否定の否定となり,かなりわかりづらい書き方になりますよね。

この場合はTrueかどうかをチェックすればOKですね。

BAD:否定の否定にしない2

否定の否定でさらにわかりづらい書き方が次のようなケースです。

_isNormalを反転させて「!_isNormal」にした状態で「!=」の比較をしています。前述のケースと似ていますが,要するにこれも「Falseの時」ということになるので,(!_isNormal)という感じで,FalseかどうかをチェックすればOKですね。

BAD:否定の否定にしない3

次のような書き方もやめましょう。ここまで来たら,解説する必要はないと思いますが,_isNormalの否定にたいして「!=」で比較し,さらに比較対象がFalseといわれると,本当に何をチェックしたいかわかりませんね。

bool型はtrueかfalseのどちらかですので,どちらの結果を得たいのか,何を判定したいのか,ということが素直にわかる形で書きましょう。また,判定する項目が複数にわたるような複雑な場合は,前述したようにメソッド化の検討が有効です。

リーダブルコードC#

C#を正しい3層構造で造れてますか?

非売品コースを受け取る

#01_はじめに
#02_プロジェクトの作成
#03_右に長いコードを書かない_隣のとなりまでしか訪ねない
#04_隣のとなりまで_右スクロールより縦スクロールの方がいい
#05_IFとELSEがある時は肯定系をIF否定形をELSEにする
#06_比較する時は変数を左_定数を右にする
#07_複数の比較を1回のif文でやらない
#08_booの比較でTrueやFalseを書かない
#09_否定の否定はしない
#10_型チェックはasを使う
#11_メソッドはできるだけ早く抜ける_返却する値を無駄に変数に入れない
#12_対象外の時はすぐに抜ける
#13_都合が悪いケースはガードする
#14_必ずやりたい処理はfinallyを使う
#15_比較演算子はできるだけクラスにさせる
#16_ifの中括弧の省略はしない
#17_if文のリーダブルコードまとめ
#18_名前の付け方
#19_意図が明確な名前を付ける
#20_名前は素直に付ける_連想ゲーム的な名前を付けない
#21_1つの事しかしていなければ短い名前でも理解できる
#22_長いクラス名の扱い方
#23_単数形と複数形で表現する
#24_対になる言葉の組み合わせを決めておく
#25_業務で使う名前は統一する
#26_名前を統一するための辞書ツール作成
#27_メンバー変数にアンダーバーを付ける
#28_ハンガリアン記法を使わない
#29_メソッド内の変数をメソッド最初に全部宣言しない
#30_メソッド内の変数は直前に宣言する
#31_ループの変数はループ内で宣言する
#32_変数を使いまわさない
#33_boolの戻り値はどちらがTrueかをわかるようにする
#34_解放が必要なオブジェクトにはusingを使う
#35_varを推奨する場合
#36_メソッド名の付け方
#37_voidとFunctionを意識する
#38_インテリセンスを意識した名前にする
#39_生成メソッドはCreate_型変換はToを使う
#40_無駄に変数に入れて返却しない
#41_重複をなくす
#42_リージョンで区切らない
#43_アクセス修飾子とsealedを付ける
#44_クラス名はソリューションエクスプローラーで並べることを意識する
#45_クラス名は名詞か名詞句で命名する
#46_クラス名で継承元や特性を表現する
#47_メソッド内にコメントを書かない
#48_分かりづらい部分はメソッド化をしてメソッド名で想いを伝える
#49_コードを読んだ人が「えっ?」と思うことが予想される場所にだけコメントを付ける
#50_コメントで悪いコードを取り繕うことはできない
#51_未実装機能はTODOコメントを書く
#52_リーダブルコードまとめ