2013-11-25 10 views
10

コードの行に関して「取得」のサイズに向けたガイドラインや一般的なコンセンサスはありますか?私はここでコードの30行にかなり簡単に成長しているメンバのGetメソッドを持っています。私はどのような時点でこれをメソッドに引き出すべきか分かりません。しかし、私はGetMyStringのようなものを呼び出すだけで、別のメンバに値を割り当て、それをコンストラクタで呼び出すことができます。Getメソッドのサイズ

これはこれまで実行する価値がありますか?

これはあまりにも主観的ですか?

+0

プロパティの具体的なガイドラインはわかりませんが、多くのベストコーディング手法では、1つの方法で7〜10行を優先する行として使用しています。 –

+3

ゲッターは何をしていますか? –

+0

良い質問です。 getterは、次の記事と同様の機能を含むクラスで使用されます。http://umerpasha.wordpress.com/2013/06/13/c-code-to-get-latest-tweets-using-twitter-api- 1-1 /クラス内の他のメンバー(例えば、すべてのOAuthトークン)から構築できる、たくさんの刺し傷があることに気付くでしょう(baseStringなど)。 –

答えて

15

dcastroの答えは良いですが、いくつかの拡張を使用することができます。

  • それは定量化さていない

を返すために長いを取ることはありません。それを定量化しましょう。プロパティは、フィールドを取得するよりも、例えば10倍以上かかる必要はありません。障害がすべき:それは

ものが遅いので、通常は最初のルールに該当しますが、これに第二の側面がある(データベース、サービス、など)外部リソースに接続しない

  • まれであるか不可能である。プロパティゲッタは例外をスローしないでください。

    • それは私が観測可能副作用のためにそれを明確にする任意の副作用

    を持っていません。プロパティゲッターは、しばしばプロパティを一度計算して後でキャッシュするという副作用がありますが、それは観察可能な副作用ではありません。

    プロパティに観測可能な副作用を持たせることは哲学的に悪いだけでなく、デバッグの経験を混乱させる可能性もあります。デフォルトでデバッガ内のオブジェクトを見ると、デバッガはそのプロパティゲッターを自動的に呼び出して結果を表示します。そうするのが遅いと、デバッグが遅くなります。そうしてしまうと、デバッグの経験が失敗メッセージでいっぱいになります。そうすることで副作用があった場合、プログラムのデバッグによってプログラムの動作が変わり、バグを見つけにくくなる可能性があります。もちろん、自動プロパティの評価をオフにすることはできますが、まず最初に適切なプロパティを設計する方がよいでしょう。

+0

エリックでキミをしてくれてありがとう!私は定量化の大きなファンではありません。私は "それは通常のデータアクセスよりもはるかに長くかかるべきではない"といい処方箋だと思う。誰が実際にどれくらい時間がかかるかを実際に測定するようなわけではありません。他のすべてについて - スポットに! +1 – dcastro

+1

@decastro:確かに、これは厳しいルールではなく、むしろ遅すぎるときの気づきの一般的なガイドラインです。別の言い方をすれば、内側ループのプロパティにアクセスすることについて心配する必要はありません。 –

+0

それは間違いなくそれを置くための良い方法です! – dcastro

2

これは、行全体をGetメソッドに移動する一般的な悪い習慣です。 私はCodeMaidというVisual Studioに何かをインストールしました。 CodeMaid Spadeと呼ばれるものがあり、それぞれの方法を評価し、スコアを与えます。スコアが高いほどあなたの方法は悪いです。これはプロパティにも使用できます。私はそれを試してみることをお勧めします。それは、書式設定、字下げ、その他の良いプラクティスの助けを借りても役に立ちます。

12

実際に重要なサイズではありません。 それは限り

  • として、それはそれはそれはdoesnの(データベース、サービス、など)
  • 外部リソースに接続しない
  • を返すために長いを取ることはありませんゲッターであなたのロジックを持って大丈夫ですどんな副作用もありません。

これは、プロパティの適切な使用に関するガイドラインの一部です。

編集

上記のガイドラインを共有する1つの理想的な:それは、ユーザーが期待するものだからプロパティアクセサは、データアクセスのように振る舞うべきです。ビル・ワグナーの著書効果的なC#のから

プロパティが データのような呼び出し側のコードから見ることができる方法です。それはあなたのユーザーの頭にいくつかの期待を寄せます。彼らは のようにデータアクセスだったかのようにプロパティアクセスを参照します。結局のところ、 のようになります。あなたの不動産のアクセサは、これらの期待に応えて になるはずです。アクセサーは、観察可能な側面を持つべきではありません 効果。アクセサーを設定すると状態が変更されますが、ユーザーは でその変更を見ることができます。

プロパティのアクセサーもパフォーマンスが になります。プロパティのアクセスは、データフィールド のように見えます。単純なデータアクセスとは大きく異なるパフォーマンス特性( )を持つべきではありません。

プロパティ が長い計算を実行、または(たとえば、データベースクエリを実行するなど)、クロスアプリケーション 呼び出しを行う、またはプロパティアクセサのため、ユーザーの期待 と矛盾だろう他の長い 操作を行うべきではないアクセサ。

アルベルトによってボーナス:一般的なガイドラインとしてhttp://msdn.microsoft.com/en-us/library/vstudio/ms229054%28v=vs.100%29.aspx

+0

これはまさに私が書こうとしていたものでした。あなたが私に尋ねるなら、「副作用」の部分が最も重要です。 –

+1

+1。任意の行の制限は厳密に - 任意です。私たちは可能な限り小さくしようと努力すべきですが、任意の制限のためにメソッドを分割することは可読性を妨げる可能性があります。 –

+0

私は、プロパティとメソッドの間の選択についての良い読書を追加したいと思います:http://msdn.microsoft.com/en-us/library/vstudio/ms229054%28v=vs.100%29.aspx – Alberto

1

、この方法は、1つの画面に収まらより多くの行を持つべきではありません。スクロールする必要がある場合は、大きすぎます。より小さな方法に分割します。

+1

私はメソッドができるだけ小さくなくてはならないと信じています。任意の制限(1つの画面 - どの解像度ですか?)のためにメソッドを他のメソッドに分割すると、読みやすさが妨げられる可能性があります。常識は任意の限界を超えています。 –

+1

その画面は? :)時には長いメソッドを持つことはうまくいきます。ロジックだけがメソッドのサイズを指定する必要があります。 –

3

それは必ずしも悪いわけではありませんが、それが私だったら私を緊張させてしまい、何とかやってみようと思います。ゲッターはメソッドなので、全体を30行以上のメソッドにするのは、私の意見では時間の無駄です。私はそれをチョップしようとしているだろう。例えば。それがいくつかのチェックを含むループであれば、メソッドをメソッドなどとして抽出します。