コーディングガイドライン：メソッドには7つ以上のステートメントを含めないでください。

私はC＃のAvSolコーディングガイドラインに目を通し、ほぼすべてに同意しましたが、特定のルールについて他の人がどう考えているかを知りたいと思います。

AV1500

メソッドは7つのステートメントを超えてはなりません。7つを超えるステートメントを必要とするメソッドは、処理が多すぎるか、責任が多すぎます。また、人間の心が正確なステートメントを分析して、コードが何をしているかを理解する必要があります。わかりやすい名前で、複数の小さくて焦点を絞った方法に分けてください。

あなたのほとんどはこのルールに従っていますか？読みやすさを大幅に向上させることは別として、新しいメソッドを作成すること（コードはまだDRYです）から節約できることはほとんどありませんか？そして、あなたの番号はまだ7と低いですか？私はもっ​​と10に向かう傾向があるでしょう。

私はあちこちでこの規則に違反していると言っているわけではありません。反対に、私の方法は95％小さくて集中していますが、この規則に違反してはいけないと言って本当に衝撃を受けました。

私は本当に誰もがこの規則に違反しないと思うことを知りたいだけです（コーディング標準の「1」です-これを絶対にしないでください）。しかし、そうでないコードベースを見つけるのに苦労すると思います。

これは私にとって「標準臭」です。特定の制限のあるコーディング標準を見るたびに、私は心配します。ほとんどの場合、メソッドは標準が許可するよりも大きくする必要がある場合に遭遇します（行の長さ/カウント、変数の数、出口点の数など）。基準はよりガイドラインに近く、適切な判断を下すための十分な余裕を持たせる必要があります。誤解しないでください、標準があることは良いことですが、それらは「プロキシによるマイクロ管理」になるべきではありません。

通常、ものを小さなメソッドに分割することをお勧めします。しかし、重要なことは、意味のある場所で物事を分割することです。

分割する意味がない場合は、分割しないでください。これは、一部の手順またはGUIコードの場合によくあります。

Steve McConnell氏はCode Completeで、短い方法を使用するときは必ずしも生産性が向上するとは限らないと述べています。意味をなさないときに分割すると、コードに複雑さを追加してもメリットはありません。

常にガイドラインと同様に、なぜ制約が存在するのかを覚えておくとよいので、いつ適用されないかを学習できます。ほとんどのコードではメソッドが短いか、おそらくDRYまたは懸念の分離に問題があります。ただし、そうでない場合は問題ありません。

それは経験則としてみなされるべきです。

「80（100,120）列以下のテキスト」、「メソッドごとに1つの出口点」、「2レベル以下のネスト」などは、コードの匂いの指標のしきい値と呼ばれます。時々それらに違反する場合、それは必ずしもコードが悪いことを意味しません。一貫してそれらに違反していることに気付いた場合は、コードに何か臭いがするので、一時停止してアプローチを再考することをお勧めします。

私にとって、最も重要な基準は、「このコードは理解可能ですか？」、「反復的ですか？」、「論理的な場所で分割されていますか？」、「疎結合ですか？」です。さらにいくつかありますが、基本的な考え方は、ドナルドクヌースのアドバイスを思い出すことによって要約できると思います。

メソッド内のステートメントの数を実際に数えるのに時間をかけたことはありませんが、明確な目的を1つだけ実行するメソッドを書くよう努めています。コードがクリーンで読みやすく、DRYおよび単一責任の原則に従っていれば、おそらく作業を完了したことになります。7ステートメントの制限を強制するためにメソッドを任意に分割すると、コードが読みにくくなり、保守しにくくなると思います。

おおよそです

これらの種類の規則は、文字通りに解釈されるべきではありません。彼らは「メソッドは短くあるべきだ」と言ったかもしれません。ただし、一部の人はそれを「1ページ未満」と解釈し、他の人は「最大2行」と解釈したでしょう。

私は彼らがあなたに大まかな考えを与えるために「7つの声明」を言ったと仮定します（私は彼らが「約7」を言ったはずだと思いますが）。時々9が必要な場合は、汗をかかないでください。しかし、20を打っている場合は、このルールの正しい球場にいないことがわかります。

7はまったく意味のない完全に任意の数値です。

循環的な複雑さは、ステートメントの数よりも大きな問題です。単一のメソッドに数百のステートメントがあるコードを見ました（これはひどいと思いました）が、循環的な複雑さは1で、実際には1つのことしかしませんでした。たくさんのステップがありました。これをより小さなメソッドに分割することについて説明しましたが、これらのメソッドはこの1つのメソッドによってのみ呼び出されます。

これはかなり極端な場合ですが、ポイントは、コードをDRYに保ち、循環的複雑度を低く保つ必要があることです。メソッドの行数よりも重要です。

たとえば、switch / caseステートメントを考えてみましょう。7つ以上の可能な値がある場合、評価を複数の方法に分割する必要がありますか？もちろん、それはばかげています。

ステートメントの数を7未満に保つためだけに、コードをより多くのメソッドに人工的に分割すると、コードが悪化します。

ガイドラインは、各メソッドが1つのことを行い、コードを乾燥した状態に保つことです。

まあ、それは少し依存します。データベースにアクセスするコードをたくさん書いています。例外処理のボイラープレートコードは、多くの場合7ステートメント以上です。私の最高のガイドラインは、あなたの機能に一つの目的があることを確認することだと思います

すべてがトレードオフです。提案されたアプローチの問題-各メソッドが短くなるようにいくつかのメソッドとクラスにリファクタリング-は、さまざまな理由で、極端に取られた場合に読み取り不能なコードにつながることです。

foo()7つのことを行うメソッドを想像してください。あなたは7つのことは多すぎると主張するかもしれません。たぶん多くの場合、あなたは正しいです。一方、これらの7つのことは密接に関連している可能性があります。ロジックはスムーズに流れ、散文のように読みます。実際に必要なときに理解するのに問題はないかもしれません。さらに悪いことに、これらの7つのものを大きなソースツリー全体に分散させるとfoo()、7つの異なる場所を見なくても何が起こるかわかりません。

多くの人々が頭の中でこのようなルールを取得し、その結果はOOスパゲッティと私が思うものです。すべてがきちんとしていて、独自の小さなメソッドまたはクラスで囲まれ、各場所でアトミックな小さなマイクロトランザクションが発生しています。しかし、そのようなコードベースに新鮮になり、それが何をしているのかを知ることは不可能です。あなたは迷子になります。

それは悪いガイドラインではありません。それらが十分にグループ化され、相互に関係している限り、メソッドとクラスを分割したことを後悔したことはありません（多すぎることはありません）。

トリックは、垂直に分割しないことです（ある時点でメソッドをつまんで、新しいメソッドを開始するだけです）。単体テストの場合と同様に、最初からこのようなルールを念頭に置いて、実際に設計を改善し、メソッドの途中で3つまたは4つのステートメントを別のメソッドに渡すことで、メソッド呼び出しがあなたがより良いことを記述しているため、コードの途中にある3つまたは4つのステートメント。

この種の分割は、それがand意的で一度しか使用されない場合でも、コードの新しい明快さのために、より良いリファクタリングにつながる可能性があります。これは小さなクラスにも当てはまります。

単体テストのように考えてください。事実の後にユニットテストを追加しようとすると、それは難しく、時には不可能に思えますが、最初からデザインする場合、実際にはすべてのコードが改善されます。

概要？「7個未満のステートメントを使用する」というデザインの匂いと「7個を超えるステートメントを使用した」というコードの匂いを比較する場合、むしろコードの匂いをなくしたいと思います。

うわー！私は、あなたの方法は非常に小さくすべきだと大雑把に言っている単純なガイドラインで、このような激しい議論を見つけることを決して期待していませんでした。彼らは常にガイドラインを明確にしたい開発者なので、私は7を選択します。

文書の冒頭ですでに免責事項を引用している人もいます。しかし、明確にするために、このドキュメントは、より良いコードを記述し、より良いシステムを設計するのに役立つガイドラインのコレクションを表しています。ガイドラインがレベル1としてマークされている場合でも、何もルールであるべきだとは言いませんでした。これらのレベルは、このドキュメントをしばらく使用している多くの人々の集合的な意見です。

また、専門家であると主張したこともありません。しかし、私はこの職業に15年間携わっており、約4年のC ++の経験と11年のC＃の経験があります。もともとはIndustrial Strength C ++に基づいていましたが、それ以来、コミュニティからの意見で改良を続けてきました。

とにかく、私が提起しようとしていたポイントは、あなた自身のために考え続けなければならないということです。7つのステートメントのガイドラインが役に立たないと思われる場合は、単に長くしてください。ちなみに、私は時々このガイドラインに違反しています。私はそれを意識して違反し、結果を受け入れます。

まず、これはガイドラインであり、ルールではありません。ガイドラインと呼ばれるので、そのように扱ってください。これは、（常に）あなた自身の判断も必要であることを意味します

それとは別に、この制約に従わない優れたコードの例がたくさん考えられます。単なるガイドラインであるにもかかわらず、貧弱なものです。

私は上の声明に同意します。これは単なるガイドラインであり、完璧な世界ではすべてがオブジェクトとなり、すべてのプログラムで再利用され、世界は美しい場所になります。それは常に真実であるとは限らず、時にはそれは多くのオーバーヘッドや無駄なリソースにつながるでしょう。それも念頭に置く必要があります。

混合物に例外処理を追加すると、非常にばかげています。

"try、catch、finally"の後、メソッドごとに4つのステートメントが残ります。

また、20個のフィールドフォームのメソッド "validateForm"を検討します。個々の検証をすべて別のメソッドで処理する場合でも、呼び出すフィールド検証メソッドは20個あります。これらのガイドラインによると、「validateTopOfScreen」、「validateMiddleOfScreen」、「validateBottomOfScreen」のような無意味な分割になります。

問題は、「ルール」と「ガイドライン」を混同することです。ルールは従うことを意味します-ガイドラインは、あなたが何をしているのか、それが本当にもっと良い方法でできるのかを検討させるためのアドバイスです。

平均して、ほとんどのプログラミングはおそらくガイドラインに従うことで改善されると思いますが、ガイドラインを独断的に守ると、意図したよりも多くの問題が発生する場合が常にあります。それがルールとしてではなくガイドラインとして提示されている理由です。

以前の回答者は、ガイドラインの作成者がそれらを独断的に適用することを決して意図していないことを示しており、その効果に関する記述をドキュメントに含めました。

上記のコメントの一部に同意します。私にとって7は任意であり、Rubyのある言語では役立つかもしれませんが、C＃、Java、C ++のような言語では、この「7行」の規則を疑います。私の現在のアプリケーションには22のテキストフィールドがあり、サーバー側の検証を行っています。このメソッドはvalidateInput（）と呼ばれ、checkEmailFormat（）のような複雑なものを検証しない限り、私の好みは1つのメソッド自体のすべてのフィールドを検証します。したがって、基本的に、validateInputメソッドのコードは108行であり、時々複雑な検証を呼び出します。

次に、各フィールドを検証するために25のメソッドを呼び出した場合を想像してください。新しい開発者が入ってきた場合、彼はメインメソッドに出入りして25のメソッドをジャンプする必要があり、これらのメソッドは他のいくつかのメソッドを呼び出している可能性があります。彼は大きなプロジェクトで迷子になります。

コードを明確にするために私が本当にしていることは、基本的にこれらの4行が元々何をしているのかを明確にコメントすることです。

validateInput（UserObj user）{

//名の検証....... ......

//姓の検証...... ......

//電子メールの検証..... //電子メールの形式を確認するには複雑すぎる通常の表現checkEmailFormat（）; .... .....

等々.. }

悪いルール。例外処理、データベースフィールドの設定、検証のコードでは、ほとんどのメソッドはどのようにして7つのステートメントの下に配置できますか？インラインラムダ関数を実行しないでください。

コードの行は、複雑さの任意のカウントです。拡張メソッドを使用すると、次のようなコードを作成できます

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

すべてのジュニアプログラマは、この原則に従うように強制する必要があります。それは彼らに忙しいものの構造を考えるように強制するでしょう、単により多くの行コードを追加するのではなく。

私は現在、たくさんのif elseステートメントと継続し、それに織り込まれたリターンを持つ550行のコードのメソッドを探しています。それはがらくたです。プログラマーが自分がやっていることについて考えることだけを強いられていた...