3

重複の可能性:
関数/プロシージャ/メソッドには何行のコードが必要ですか?

関数には何行のコードが必要ですか?行数が多すぎます。

しばらく前に読んだのですが、10行か20行くらいでしたが、画面があまりにも多くの行しか収容できないためでした。画面サイズが大きくなると、それは当てはまりません。

関数のどの部分も他の場所で使用されていないと仮定しましょう。つまり、DRYの原則を無視します。

これについて他の人が言っていることを聞きたいです。

ありがとう。

関数が長すぎるのはいつですか?、投稿時に見つかりませんでした。

4

10 に答える 10

17

行は関係ありませんが、複雑さは関係があります。

関数は 1 つのタスクを実行する必要があり、すぐにわかる必要があります。関数がどのように、また何を行うのかを正確に理解するのに数分以上かかることはありません。

于 2010-06-04T18:45:33.393 に答える
6

この種の質問はCode Completeでよく答えられています。Steve McConnel は、この質問に答えるためにページ全体を書きました。彼の結論:

何十年にもわたる証拠によると、このような長さ (>100 行) のルーチンは、短いルーチンよりもエラーが発生しにくいということです。ルーチンの結束、決定点の数、ルーチンを説明するために必要なコメントの数、およびその他の複雑さに関連する考慮事項などの問題によって、長さの制限自体を課すのではなく、ルーチンの長さが決まります。とはいえ、約 200 行を超えるルーチンを書きたい場合は注意が必要です。

于 2010-06-04T18:57:12.950 に答える
4

必要な数が必要です。

関数の行数を画面サイズに制限する意味がわかりません(公平を期すために、画面が10〜20行以上に対応できるようになるまでプログラミングを開始しませんでした-おそらくこれは一部の環境では意味がありました) . 意味のある関数を書くだけです。コードの断片が繰り返されるほど大きくなったら、それらの断片を他の関数/クラス/コンポーネントにリファクタリングします。

于 2010-06-04T18:43:16.750 に答える
2

これはかなり恣意的な経験則です。20 行が好きな人もいれば、スクロールなしのルールが好きな人もいます。最後に、読みやすく、一目で簡単に理解できるようにしてください。SOLID の原則を読み 、メソッドの責任が 1 つだけであることを確認します。

于 2010-06-04T18:43:35.037 に答える
1

必要なだけ長く、できるだけ短く。

経験則として 5 ~ 10 行を使用しますが、複数の関数に簡単に (リ) ファクタリングできないロジックがある場合は、必要に応じてより長く記述します。一方、私はしばしば1行または2行の長さの関数を持っています。

コードの一部が何をするのかすぐに理解できない場合は、新しい関数を作成してください。

于 2010-06-04T18:47:46.500 に答える
0

効率的である限り、行数は関係ないと思います。

コードベースのどこでも再利用できるコードは、同じクラスまたは共有クラス内の別の関数/メソッドに移動して呼び出す必要があります。

于 2010-06-04T18:43:56.190 に答える
0

画面サイズのメトリックも以前に聞いたことがありますが、明らかにハードリミットやモニターサイズに合わせたスケーリングを意図したものではありません. これは、DRY の原則を伝えることを目的としており、関数をできるだけ小さく保つことが (プロジェクト サイズで) スケーリングできるコードを記述する最良の方法の 1 つであることを示しています。

于 2010-06-04T18:44:43.367 に答える
0

Linux カーネル コーディング スタイル ドキュメントには次のように書かれています。

関数は短くて魅力的で、1 つのことだけを行う必要があります。それらは 1 つか 2 つの画面いっぱいのテキスト (ISO/ANSI の画面サイズは 80x24 であることは周知のとおりです) に収まる必要があり、1 つのことを適切に実行する必要があります。

さて、これはカーネルコードのコンテキストにあることに気づきましたが、関数の長さに関していくつかのポイントが一般的に有効であると思います。ここでコピーを見つけてください。関数のセクションは第 4 章です。

全体として、関数の長さは人為的な規則によって制約されるべきではありません。理にかなっている場合は要素を除外し、読みやすくするためですが、1〜2画面に関するルールは決まったものではありません.

于 2010-06-04T18:49:23.243 に答える
0

これは、OO の観点からの単なる意見です。

私は自分のメソッドを論理的な作業単位に保つことを好み、LoC のようなメトリクスはあまり気にしません。これにより、メソッドに適切な名前を付けるのも非常に簡単になり、メソッドが肥大化するのを防ぎます。

非常に些細な機能の例は、ループ内でフィボナッチ数列をインラインで計算する関数を使用する代わりに、fibonacci() 関数によって呼び出されるサクセサ (int a,int b) 関数を追加することです。

OO 形式のより複雑な例は、GET 要求を実行する http クライアントです。私はそれを次のようなものに分割します:

Connection getConnection(String host, int port)
Request createRequest(String[] params)
void sendRequest(Request r)
String getResponse(Connection c,Request r)
于 2010-06-04T19:02:11.410 に答える
0

関数は、その仕事をするのに十分なほど小さくなければなりませんが、小さくしてはいけません。

于 2010-06-04T19:23:19.710 に答える