C#と諸々

C#がメインで他もまぁ諸々なブログです
おかしなこと書いてたら指摘してくれると嬉しいです(´・∀・`)
つーかコメント欲しい(´・ω・`)

--/--/-- --:--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
タグ:
トラックバック(-) | コメント(-) | このエントリーを含むはてなブックマーク
2007/02/20 02:10
久々のコーディング俺規約です。
R.田中一郎さんの記事を読んで、僕もふと、コーディングのたびに気になる事を思い出しました。

何かと言うと、usingブロック内で得た値を戻り値で返す場合です。
例えば、

public string Foo()
{
    using (Hoge hoge1 = new Hoge())
    {
        hoge1.Fuga = "ふがふが";
        string piyoResult = hoge1.Piyo():
        return piyoResult;
    }
}

と書くか、

public string Foo()
{
    string piyoResult;
    using (Hoge hoge1 = new Hoge())
    {
        hoge1.Fuga = "ふがふが";
        piyoResult = hoge1.Piyo():
    }
    return piyoResult;
}

と書くか。

前者はusingブロックの中でreturnして、後者はusingブロックを抜けた後でreturnしてます。
こういう時は、僕の場合前者、つまりusingブロックの中でreturnしてしまいます。

でも、hoge1オブジェクトの操作を終えた後、「他の処理」が少々入る場合は、

public string Foo()
{
    using (Hoge hoge1 = new Hoge())
    {
        hoge1.Fuga = "ふがふが";
        string piyoResult = hoge1.Piyo():
        string fooResult = piyoResult.Replace('-', '_')
        return fooResult;
    }
}

と書くのではなく、

public string Foo()
{
    string piyoResult;
    using (Hoge hoge1 = new Hoge())
    {
        hoge1.Fuga = "ふがふが";
        piyoResult = hoge1.Piyo():
    }
    string fooResult = piyoResult.Replace('-', '_')
    return fooResult;
}

という風に書きます。
理由は、「他の処理」を行う前にusingブロックを抜けることができるのに、無駄にhoge1を延命させてしまうのは無意味だからです。
「他の処理」が複数行に渡る場合、hoge1オブジェクトが既に不要となっていることが一目ではわかりづらいし、「他の処理」が重い場合、それだけ解放処理 ( Dispose ) が遅くなります。

こっちのパターンはこれでいいです。そんな気がします。
でも、最初のパターン、つまり「他の処理」が入らないパターンも、統一してusingブロックの前でreturnするべきな気がしてきます。

いやまてよ・・・、そもそもreturnの位置は重要でなく、usingブロックの範囲が重要なのかな。「他の処理」が入らずreturnするだけなら、usingブロック内に含めても何ら問題ないもんなぁ。その方が可読性は良いし。hoge1オブジェクトを操作する処理が複数行ある場合なんて特にそうですしね。
うん、そんな気がしてきた!そうすると、returnの位置は臨機応変ってことになりますね。

・・・ってことで、結局今まで通りでいいのかな?w
スポンサーサイト
2006/10/08 02:06
C#のコーディング規約。
基本はクラス ライブラリ開発のデザイン ガイドラインに従うとして、それ以外の範囲で俺的な規約。

[ 俺規約 ]
自身のインスタンスメンバには、thisキーワードを必ず付ける。

[ 理由 ]
・自身のインスタンスメンバであることが一目でわかり、可読性が向上する。 ( ローカル変数とインスタンスフィールドを一目で区別できる。静的メソッドとインスタンスメソッドを一目で区別できる。 )
・インテリセンスも利用できるし。
・" this. " というたった5文字を入力することによる手間・冗長化なんてたいした事ない。それよりも可読性の向上、インテリセンスの利用といったメリットの方が遥かに大きい。

[ 補足 ]
同様に、自身の静的メンバには、クラス名を必ず付ける。 なんとなく不自然さを感じるけど我慢。あと、VS2003では、クラス名が変更されたときに自分でちゃんと置換を行わないといけないので注意。 ( まぁ、それは " 自身の " に限らないけど。 )
つーか、自身の静的メンバを参照するためのキーワードがあればいいのにな (´・ω・`;)
2006/09/13 23:40
C#のコーディング規約。
基本はクラス ライブラリ開発のデザイン ガイドラインに従うとして、それ以外の範囲で俺的な規約。

[ 俺規約 ]
フィールドの初期化はフィールドの定義時ではなく全てコンストラクタで行う。

[ 理由 ]
・フィールドの定義と一緒に初期化しても、その後コンストラクタで更に初期化される可能性があるから。(読みづらい上に、無駄。)
・あるフィールドでは定義と一緒に初期化して、あるフィールドでは定義で初期化せずコンストラクタで初期化してじゃ読みづらい。

[ 補足 ]
静的フィールドも同様に静的コンストラクタで初期化する。
静的フィールドは、定義時に初期化し、静的コンストラクタを明示的に宣言しないこと。
詳細はこちらの記事を参照。


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。