Javaメソッド名が長すぎますか？
先週、メソッドまたはクラス（50文字）に非常に長い名前を使用している人を見てきましたが、これは通常、読みやすさを向上させることを前提としています。私の意見では、このような長い名前は、このような長い名前が必要な場合は、メソッドクラスで多くのことを行うか、あまりにも多くのことをしようとしますが、私はあなたたちがそれについてどう思うか知りたいと思いました。
例は次のとおりです。
getNumberOfSkinCareEligibleItemsWithinTransaction
メソッドの動作を均等に伝える短い名前が存在する場合、Javaまたは他の言語の名前は長すぎます。
メソッド名の長さを短くするためのいくつかのテクニック：
プログラム、クラス、またはモジュール全体が「スキンケアアイテム」に関するものである場合は、スキンケアを削除できます。たとえば、クラスの名前が
SkinCareUtilsの場合、getNumberOfEligibleItemsWithinTransactionに移動しますwithinをin、
getNumberOfEligibleItemsInTransactionに変更できますTransactionをTxに変更すると、
getNumberOfEligibleItemsInTxに移動できます。または、メソッドが
Transaction型のパラメーターを受け入れる場合、InTxを完全にドロップできます：getNumberOfEligibleItemsカウントによってnumberOfを変更します：
getEligibleItemsCount
今ではそれは非常に合理的です。そして、それは60％短くなります。
変更のために、非主観的な回答：65536文字。
A.Java:1：文字列 "xxxxxxxxxxxxxxxxxxxx ..."のUTF8表現が定数プールに対して長すぎます
;-)
私は全員に同意します。メソッド名は長すぎてはいけません。ただし、例外を1つ追加します。
ただし、JUnitテストメソッドの名前は長くなる可能性があり、文に似ている必要があります。
どうして？
- 他のコードでは呼び出されないためです。
- テスト名として使用されるためです。
- なぜなら、それらは要件を記述する文として書くことができるからです。 （たとえば、 AgileDox を使用します）
例：
@Test
public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() {
...
}
このアイデアの詳細については、「 Behavior Driven Design 」を参照してください。
コンテキスト「... WithinTransaction」は明らかです。それがオブジェクト指向です。
このメソッドはクラスの一部です。クラスが「トランザクション」を意味しない場合、そして常に「WithinTransaction」を言う必要がなくなる場合、問題が発生します。
私はよく名前に俳句ルールを使用します：
Seven syllable class names
five for variables
seven for method and other names
これらは最大名の経験則です。読みやすさが向上する場合にのみ、これに違反します。 recalculateMortgageInterest（currentRate、quoteSet ...）のようなものは、recalculateMortgageInterestRateやrecalculateMortgageInterestRateFromSetよりも優れています。というのは、レートと引用符のセットが含まれているという事実は、javadocや.NETの同等物のような埋め込みドキュメントからかなり明確になるからです。
注：5-7-5ではなく7-5-7であるため、実際の俳句ではありません。しかし、私はまだ俳句と呼んでいます。
Javaには長い名前を奨励する文化があります。おそらくIDEには優れたオートコンプリート機能が備わっているからです。
このサイト は、JREで最も長いクラス名がInternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedStateで、92文字の長さであることを示しています。
最長のメソッド名については、これがsupportsDataDefinitionAndDataManipulationTransactions（52文字）であることがわかりました。
ちっぽけな言葉を使うときは長い言葉を使わないでください。
「メソッド名の長さはメソッドの長さに比例する」というあなたの論文には本当に意味があるとは思いません。
「getNumberOfSkinCareEligibleItemsWithinTransaction」の例を使用してください。それはただ一つのことをするように私には聞こえます：それは特定のカテゴリに分類されるトランザクション内のアイテムの数をカウントします。もちろん、メソッドの実際のコードを見ずに判断することはできませんが、それは良い方法のように思えます。
一方、「processSale」やこれまでに人気のある「doStuff」など、非常に短く簡潔な名前のメソッドが多く見られます。
メソッド名の長さについて厳格なルールを与えるのは難しいと思いますが、目標は次のとおりです。関数が何をするのかを伝えるのに十分な長さ、読みやすいほど短い。この例では、おそらく「getSkinCareCount」で十分だと思います。問題は、何を区別する必要があるかです。トランザクションでスキンケアに適格なアイテムを数える関数と、他の何かにスキンケアに適格なアイテムを数える関数がある場合、「withinTransactions」は価値を追加します。しかし、トランザクション以外でそのような項目について話すことを意味しない場合、そのような余分な情報で名前を乱雑にする意味はありません。
2つ目は、管理可能な長さの名前が、最も些細な場合を除いて、関数が何をするかを正確に伝えると考えるのは、非常に非現実的だと思います。現実的な目標は、読者に手がかりを与え、後で覚えられる名前を作ることです。たとえば、ワープ速度に達するために必要な反物質の量を計算するコードを見つけようとしている場合、関数名を見て「calibrateTransporter」、「firePhasers」、「calcAntimatterBurn」を見ると、最初の2つはそうではありませんが、3つ目はそうかもしれません。実際にそれが私が探しているものであることを確認して見つけたら、明日戻ってこの問題に取り組むためにもう少し思い出すのは簡単です。それで十分です。
3つの類似した長い名前は、短い名前よりも紛らわしいです。 「calcSalesmanPay」と「calcGeekPay」という2つの関数がある場合、一目でどちらが正しいかを推測できます。しかし、それらが「calculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation」および「calculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation」と呼ばれる場合、どの名前であるかを確認する必要があります。そのような場合、名前の余分な情報はおそらく逆効果です。半秒の思考を30秒の思考に変えます。
インターフェースを思い通りに設計し、実装を一致させます。
たとえば、多分私はそれを
getTransaction().getItems(SKIN_CARE).getEligible().size()
またはJava 8ストリーム：
getTransaction().getItems().stream()
.filter(item -> item.getType() == SKIN_CARE)
.filter(item -> item.isEligible())
.count();
私のルールは次のとおりです。名前が長すぎて1行に表示する必要がある場合は、長すぎます。 （実際には、これは20文字を超えることはめったにないことを意味します。）
これは、目に見えるコードの垂直線の数がコーディング速度/有効性と正の相関があることを示す調査に基づいています。クラス/メソッド名がそれを著しく傷つけ始めたら、それらは長すぎます。
メソッド/クラスが宣言されている場所にコメントを追加し、その目的の詳細な説明が必要な場合はIDEでそこに連れて行ってください。
メソッド自体の長さは、多すぎるかどうかのより良い指標である可能性が高く、それでも大まかなアイデアを提供するだけです。簡潔さのために努力する必要がありますが、記述性はより重要です。短い名前で同じ意味を伝えることができない場合、名前自体はおそらく大丈夫です。
次回メソッド名を書くときは、以下の引用を考えてください
"The man who is going to maintain your code is a phyco who knows where you stay"
変数名が長すぎると、プログラム全体またはプログラムの重要な部分でコードの読みやすさが向上します
長い名前を使用すると、値に関する詳細情報を伝達できます。ただし、名前が長すぎると、コードが乱雑になり、残りのコードを理解する能力が低下します。これは通常、行の折り返しを引き起こし、ページの他のコード行をプッシュすることで発生します。
秘Theは、どちらが読みやすくなるかを決定することです。変数が短いスペースで頻繁にまたは数回使用される場合は、短い名前を付けてコメントを明確にすることをお勧めします。読者は簡単にコメントを参照できます。変数がプログラム全体で頻繁に使用される場合、多くの場合パラメーターまたはその他の複雑な操作で使用される場合は、名前を切り詰めるか、頭字語を読者に思い出させるために使用するのが最善です。意味を忘れた場合、変数宣言によってコメントを常に参照できます。
これは簡単なトレードオフではありません。コードリーダーが理解しようとしているものを考慮し、コードが時間とともにどのように変化し成長するかを考慮する必要があるためです。それが物事の命名が難しい理由です。
DescriptiveLoopCounterNameの代わりにiをループカウンターとして使用することが許容される理由は、読みやすさです。これは変数の最も一般的な使用方法であるため、存在する理由を説明する画面スペースを最小限に抑えることができます。長い名前は、ループ条件のテストや配列へのインデックス付けの方法を理解しにくくすることで、時間を無駄にするだけです。
スペクトルのもう一方の端では、マルチパラメーター関数呼び出しに渡されるなど、複雑な操作のように関数または変数がめったに使用されない場合、過度に説明的な名前を付ける余裕があります。
そのメソッド名は間違いなく長すぎます。このようなサイズのメソッド名を読んでいると、私の心はさまよう傾向があります。それはスペースなしで文章を読むようなものです。
個人的には、メソッド内の可能な限り少ない単語を好みます。パッケージとクラス名が意味を伝えることができれば助けられます。 クラスの責任が非常に簡潔な場合、巨大なメソッド名は必要ありません。なぜ「WithinTransaction」がそこにあるのか興味があります。
「getNumberOfSkinCareEligibleItemsWithinTransaction」は次のようになります。
com.mycompany.app.product.SkinCareQuery.getNumEligibleItems（）;
次に、使用中のメソッドは「query.getNumEligibleItems（）」のようになります。
メソッドの名前が別の行に折り返され、そのメソッドへの呼び出しがその行で唯一のものであり、マージンのかなり近くで始まる場合、長すぎます。あなたはそれを使用する人々の画面の平均サイズを考慮する必要があります。
しかし！名前が長すぎると思われる場合は、おそらく長すぎます。それを回避する方法は、コンテキスト内にあり、名前は短いが他のコンテキストでは複製されるような方法でコードを書くことです。これは、誰かのフルネームの代わりに英語で「彼女」または「彼」と言うことができるようなものです。
他の言語と同様：関数が実行する単一のアクションを記述しなくなったとき。
良い答えを組み合わせて使用し、合理的であると思います。
メソッドが何をするかを完全に、明確に、そして読みやすく説明してください。
メソッド名が長すぎると思われる場合は、メソッドをリファクタリングして、処理を少なくします。
物事が何であるかを冗長に説明しすぎると、長すぎます。
たとえば、これらの名前は機能的に同等です。
javaの場合：Java.sql.SQLIntegrityConstraintViolationException
python/Djangoの場合：Django.db.IntegrityError
SQL/dbパッケージで、どのくらいの種類の整合性エラーが発生する可能性があるかを自問してください。 ;）したがって、db.IntegrityError 十分なものです。
識別子名は、Javaコンパイラが処理できる長さを超えると長すぎます。
ここには2つの方法または視点があります：1つは、メソッドが何をしているのかをできるだけ記述的に記述している限り、メソッド名の長さは本当に重要ではないということです（Javaのベストプラクティスの基本ルール）。一方、私はflybywireの投稿に同意します。知性を使用して、メソッド名をできる限り減らすようにしますが、記述性は低下させません。記述性はより重要です:)
次の場合、名前が長すぎます。
- 読むのに1秒以上かかります
- JVMに割り当てるより多くのRAMを使用します
- とんでもない名前が付けられたものです
- 短い名前が完全に理にかなっている場合
- IDEでラップアラウンドする場合
正直なところ、名前は、パブリックAPIメソッドとして使用する開発者にその目的を伝えるか、または離れるときにコードを維持する必要があるだけです。 KISS（単純な愚かさを保つ）