あなたの経験では、Javaの1つのクラスに対して何行のコードが多すぎるかを知るのに役立つ経験則は何ですか?
明確にするために、特定のクラスにあるべきものとそうでないものに使用するための行数は実際の標準にさえ近づいていないことを知っています。クラスは、適切なOOP哲学(カプセル化など))に従って設計する必要があります。つまり、経験則は、リファクタリングの考慮事項(つまり、このクラス> n行のコードがあります。おそらく読めず、カプセル化というお粗末な仕事をしているので、いつかリファクタリングする必要があるかどうかを確認したいかもしれません。」.
反対に、おそらくOOP設計に従っており、長さにもかかわらず読みやすく、保守可能であった非常に大きなクラスの例に遭遇しましたか?
関連する重複しない 関数ごとの行に関する質問 を次に示します。
いくつかの興味深い指標:
junit fitnesse testNG tam jdepend ant Tomcat ----- -------- ------ --- ------- ---- ----- 最大500 498 1450 355 668 2168 5457 平均64.0 77.6 62.7 95.3 128.8 215.9 261.6 分4 6 4 10 20 3 12 シグマ75 76 110 78 129 261 369 ファイル90 632 1152 69 55 954 1468 合計行数5756 49063 72273 6575 7085 206001 384026
私はそれを書くことに多くのことをしたので、FitNesseをベンチマークとして使用します。 FitNesseでは、平均クラスは77行です。 498行を超えるものはありません。そして標準偏差は76ラインです。つまり、クラスの大部分は150行未満です。 5000行を超えるクラスが1つあるTomcatでさえ、ほとんどのクラスは500行未満です。
これを踏まえると、200行を下に留まるための適切なガイドラインとして使用できます。
私にとって、コード行はこのコンテキストでは関係ありません。それは、私がこのクラスに変更を加えるために来るさまざまな理由のすべてについてです。
Personを検証するためのルールを変更したいときにこのクラスに来た場合、同じクラスに来てOrderを検証するためのルールを変更したくありません。 Personを永続化します。
そうは言っても、200行を超えるクラスはめったに見つかりません。それらは正当な理由で起こりますが、まれです。したがって、赤旗の指標を探しているなら、それは開始するのに悪い場所ではありません。しかし、それをルールではなくガイドラインにしてください。
申し訳ありませんが、多くの回答で「それほど重要ではない」と回答されていることに非常に驚いています。クラス内の行数は非常に重要です。どうして?良いJavaコードを書く際にこれらの原則を考慮してください...
多数の行が含まれているクラスは、これらの原則のすべてに違反する可能性があります。
「本当に重要ではない」と言った人にとっては、5000行以上あるクラスを試して理解するのはどれほど楽しいですか。または、それを変更するには?それが楽しいと言うなら、あなたは痛みに対して奇妙な親和性を持っています...
1000行を超えるクラスはすべて、 少なくとも それらが上記の原則にどのように違反しているかについて質問され、おそらくいくつかの「オフシュート」クラスに解析されます。
私のコメントは、Martin Fowler、Joshua Bloch、Misko Heveryなどの著者を読んで研究したことに基づいています。良いJavaコードを書くために相談するのに優れたリソースです。
次の男(数年後にはあなたかもしれません)を支持して、行数を増やすのではなく、減らすクラスを書くように努力してください。
行数ではなく、複雑さに依存します。私は理解しやすく、正確に1つのことを行い、それをうまく行った大きなダムルーチンを作成しましたが、何百行も続きました。私は理解する(そしてデバッグする)のが難しいかなり短い関数を書きました。
あなたが見ることができるもう一つは、クラス内のパブリック関数の数です。これは警告のサインにもなります。
十分な数はありませんが、あなたの店で役立つことをするきちんとしたコードを見て、それをもとにしてみることをお勧めします。確かに、最も長いクラスと最大のAPIを確認する必要があります。
正解は42です。冗談です。
実際には、クラスごとの最大推奨行は 2000年 ライン。
1999年以降の「Javaコード規約」では、次のように述べています。
2000行を超えるファイルは扱いにくく、避ける必要があります。
Javaが発明されて以来、Sun/Oracleのコーディング規約に従っているので、クラスごとの行数に関するこの経験則は妥当であることがわかりました。Javaの99% =コードは準拠する必要があります...そして2000年を超える場合は、クラスに作業が必要であることを示すTODOを先頭に配置してください。
最悪なのは、プログラマーが非常に多くの小さなクラスを作成し、各クラスに実際の機能がほとんどない場合とは逆です。 「お気に入りの構成」へのアドバイスを無視して、プログラマーは何百もの継承クラスを作成し、これは複雑なオブジェクトモデルを作成します。これは、大規模なクラスの問題(少なくとも通常、関連するクラス名で機能を維持する)よりもさらに悪いものです。
http://www.Oracle.com/technetwork/Java/javase/documentation/codeconventions-141855.html#304
クラスが非常に多くの異なることをしている場合、コードの行が多すぎます。基本的に、クラスの単一責任の原則に従う場合、クラスの規模には制限があります。
物理的な制限については、(ソース: クラスファイル形式Java5 ):
つまり、クラスファイルは、anyoneが有用だと考えるよりもはるかに大きくなる可能性があります。単一責任の原則に固執する場合、クラスファイルは適切なサイズになります。
クリーンコード:
クラスは小さくなければなりません!
クラスの最初のルールは、それらが小さいことです。クラスの2番目のルールは、それよりも小さいことです。いいえ、「関数」の章とまったく同じテキストを繰り返すことはしません。しかし、関数の場合と同様に、クラスの設計に関しては、小さい方が原則です。関数と同様に、当面の質問は常に「どれほど小さいか」です。
**関数では、物理的な線を数えることでサイズを測定しました。クラスでは、別のメジャーを使用します。私たちは責任を数えます。**
クラスの名前は、それが果たす責任を説明する必要があります。実際、命名はおそらくクラスのサイズを決定する最初の方法です。 クラスの簡潔な名前を導出できない場合、その名前は多すぎる可能性があります。クラス名があいまいであるほど、責任が多すぎる可能性があります。たとえば、Processor、Manager、Superなどのイタチの単語を含むクラス名は、責任の不幸な集約を示唆することがよくあります。
次に:
扱いやすいサイズのクラスになります。
より適切なメトリックを使用してみてください。
1つの例はABC Metricです。これは、コードの量よりも、コードによって実行されている量の測定値です。
行数は、クラス品質のかなり悪いメトリックです。私にとって、私は(他の人が述べたように)パブリックメソッドとパブリックに公開されたプロパティ(Javaのパブリックゲッター/セッターを推測している)を見るのが好きです。それが私の注意を引くかもしれないときに私が空気から数を引き出さなければならなかったならば、私はそれぞれが10を超えるとき言うでしょう。実際、プロパティまたはメソッドのいずれかが5を超える場合は、調べてリファクタリングする方法を見つけることがよくありますが、10を超えると、通常、何かが十分に公開されていない可能性がかなり高いという警告サインです。
完全に別の会話ですが、プライベートメソッドとフィールドは私にとってはあまりにおいが少ないので、それらが行数に大きく貢献しているのであれば、それほど心配することはないかもしれません。少なくとも、遠くからオブジェクトを操作する神のコントローラーがいないことを示しています。これは、かなり問題のある設計上の問題です。
クラスの外に書かれたクラスの問題ドメイン内にある行は、それが存在するクラスでは1行が少なすぎ、1行が多すぎます。クラスをトピックと考えてください。あなたはそれをカバーする必要があります。できるだけ簡潔にするのが理想ですが、500行かかる場合は500行かかります。それらの100行が別のトピックをカバーしている場合、それらは別の場所に属しています。内部クラスとしてクラス内の小さなサブドメインに分割することは理にかなっていますが、他の場所で使用した場合にのみ、クラスの外部のサブドメインを定義します。