C#リーダブルコード #14_必ずやりたい処理はfinallyを使う

今回は「必ずやりたい処理はfinallyを使う」というお話をしていきたいと思います。

1.1 GOOD:必ずやりたい処理はfinallyを使う

前述のように，「都合の悪いケースではすぐに抜ける」場合など，すぐに抜けるのは良いのですが，毎回最後にログを書きたい等，必ずやりたい処理がある場合があります。そういった場合は，finallyを使用してください。

//GOOD:必ずやりたい処理はfinallyを使う
private bool 必ずやりたい処理はfinallyを使う(Product product)
{
    Console.WriteLine("in");
    try
    {
        if (product == null)
        {
            return false;
        }

        if (product.ProductName == null)
        {
            return false;
        }

        if (product.ProductName.Length <= 3)
        {
            return false;
        }

        return product.ProductName.Substring(2, 1) == "A";
    }
    finally
    {
        Console.WriteLine("out...");
    }
}

//GOOD:必ずやりたい処理はfinallyを使う

private bool 必ずやりたい処理はfinallyを使う(Product product)

{

Console.WriteLine("in");

try

{

if (product == null)

{

return false;

}

if (product.ProductName == null)

{

return false;

}

if (product.ProductName.Length <= 3)

{

return false;

}

return product.ProductName.Substring(2, 1) == "A";

}

finally

{

Console.WriteLine("out...");

}

これはリーダブルコードというよりは，ただのC#の仕様ですが，最後に何かやりたいことがあるという理由で，すぐに抜ける書き方ではなく，一度変数に退避して，最後にリターンするという記述をする場合もあるかもしれないので，そういった場合も，finallyを使えば，すぐに抜けるパターンでも，必ずやりたい処理を通せますよというお話です。やり方は，tryキーワードで囲って，最後にfinallyキーワードですね。try｛｝の中で何が起きようとfinallyを通るので，どの条件にヒットしようとやりたいことや，最後にログを記述するような場合に使えます。要するに，早々にreturnする書き方をしながら，必ずやりたいことも書くことができるということです。そういった場合は，finallyを検討してみてください。

リーダブルコード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_リーダブルコードまとめ