Javaメソッド名が長すぎるのはいつですか？[閉まっている]

ここ数週間、メソッドまたはクラスに非常に長い名前（50文字）を使用している人を見たことがありますが、これは通常、読みやすさを向上させることを前提としています。このような長い名前は、このような長い名前が必要な場合は、メソッドクラスで多くまたは多くのことを試みますが、皆さんはそれについてどう思いますか。

例は次のとおりです。

getNumberOfSkinCareEligibleItemsWithinTransaction

メソッドの動作を同等に伝える短い名前が存在する場合、Javaまたはその他の言語の名前は長すぎます。

メソッド名の長さを減らすためのいくつかのテクニック：

1. プログラム全体、クラス、またはモジュールが「スキンケアアイテム」に関するものである場合は、スキンケアを削除できます。たとえば、クラスがと呼ばれるSkinCareUtils場合、getNumberOfEligibleItemsWithinTransaction

2. あなたは変更することができ以内にで、getNumberOfEligibleItemsInTransaction

3. TransactionをTxに変更すると、に移動できますgetNumberOfEligibleItemsInTx。

4. または、メソッドがタイプのパラメータを受け入れる場合はTransaction、InTxを完全に削除できます。getNumberOfEligibleItems

5. カウントによってnumberOfを変更します。 getEligibleItemsCount

今ではそれは非常に合理的です。そしてそれは60％短くなります。

変更のためだけに、主観的でない答え：65536文字。

A.java:1：文字列 "xxxxxxxxxxxxxxxxxxxx ..."のUTF8表現は、定数プールには長すぎます

;-)

私は皆に同意します：メソッド名は長すぎてはいけません。ただし、例外を1つ追加したいと思います。

ただし、JUnitテストメソッドの名前は長くなる可能性があり、文章に似ている必要があります。

どうして？

• 他のコードでは呼び出されないためです。
• テスト名として使用されるためです。
• なぜなら、それらは要件を説明する文章として書くことができるからです。（たとえば、AgileDoxを使用）

例：

    @Test
    public void testDialogClosesDownWhenTheRedButtonIsPressedTwice() {
        ...
    }

このアイデアの詳細については、「ビヘイビア駆動設計」を参照してください。

コンテキスト「... 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であるため、実際の俳句ではありません。しかし、私はそれを俳句と呼ぶのを好む。

おそらくIDEには優れたオートコンプリート機能が備わっているため、Javaには長い名前を奨励する文化があります。

このサイトによると、JREで最も長いクラス名InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedStateは92文字です。

最も長いメソッド名supportsDataDefinitionAndDataManipulationTransactionsは52文字です。

ちっぽけな単語で十分な場合は、長い単語を使用しないでください。

「メソッド名の長さがメソッドの長さに比例する」というあなたの論文は、本当に水を持っているとは思いません。

「getNumberOfSkinCareEligibleItemsWithinTransaction」の例を見てみましょう。これは、1つのことだけを行うように思えます。特定のカテゴリに分類されるトランザクション内のアイテムの数をカウントします。もちろん、メソッドの実際のコードを確認せずに判断することはできませんが、それは私には良い方法のように思えます。

一方、「processSale」や今まで人気の高い「doStuff」のように、多くの作業に役立つ非常に短くて簡潔な名前を持つ多くのメソッドを見てきました。

メソッド名の長さに関して厳格な規則を与えるのは難しいと思いますが、目標は、関数が何を実行するかを伝えるのに十分長く、読みやすいように十分に短くすることです。この例では、おそらく「getSkinCareCount」で十分だったと思います。問題は、何を区別する必要があるかです。スキンケア対象アイテムをトランザクションでカウントする関数と、スキンケア対象アイテムを別のアイテムでカウントする関数がある場合、「withinTransactions」は価値を追加します。しかし、トランザクションの外でそのようなアイテムについて話すことが何の意味もないのであれば、そのような余分な情報で名前を混乱させる意味はありません。

2つ目は、管理しやすい長さの名前から、関数が何を行うかを、非常に些細な場合を除いて正確に説明できると考えるのは、非常に非現実的だと思います。現実的な目標は、読者に手掛かりを与え、後で思い出せる名前を付けることです。たとえば、ワープ速度に到達するために消費する必要がある反物質を計算するコードを見つけようとしている場合、関数名を見て「calibrateTransporter」、「firePhasers」、および「calcAntimatterBurn」を見ると、かなり明らかです。最初の2つはそうではありませんが、3つ目はそうかもしれません。確認し、それが本当に探しているものであることがわかった場合、明日この問題に取り組むために戻ってきたときに、それを思い出すのは簡単です。それで十分です。

類似した3つの長い名前は、短い名前よりも混乱します。「calcSalesmanPay」と「calcGeekPay」という2つの関数がある場合、どれがどれであるかが一目でわかります。しかし、それらが「calculateMonthlyCheckAmountForSalesmanForExportToAccountingSystemAndReconciliation」および「calculateMonthlyCheckAmountForProgrammersForExportToAccountingSystemAndReconciliation」と呼ばれている場合、どちらがどれかを確認するために名前を調べる必要があります。名前の追加情報は、おそらくそのような場合には逆効果です。0.5秒の思考を30秒の思考に変えます。

インターフェイスを希望どおりに設計し、実装を一致させます。

たとえば、多分私はそれを次のように書くでしょう

getTransaction().getItems(SKIN_CARE).getEligible().size()

またはJava 8ストリーム：

getTransaction().getItems().stream()
    .filter(item -> item.getType() == SKIN_CARE)
    .filter(item -> item.isEligible())
    .count();

私のルールは次のとおりです。名前が長すぎて、それ自体の行に表示する必要がある場合は、長すぎます。（実際には、これは20文字を超えることはめったにないということです。）

これは、コードの目に見える垂直線の数がコーディング速度/有効性と明確に相関していることを示す調査に基づいています。クラス/メソッド名が著しくそれを傷つけ始める場合、それらは長すぎます。

メソッド/クラスが宣言されている場所にコメントを追加し、その目的について長い説明が必要な場合はIDEがその場所に移動できるようにします。

メソッド自体の長さは、それが多すぎるかどうかのより良い指標である可能性が高く、それでもおおまかなアイデアしか得られません。簡潔さを追求する必要がありますが、説明が重要です。短い名前で同じ意味を伝えることができない場合、名前自体はおそらく大丈夫です。

次回、メソッド名を書くときは、次の引用を考えてください。

"The man who is going to maintain your code is a phyco who knows where you stay"

そのメソッド名は明らかに長すぎます。そのようなサイズのメソッド名を読んでいると、私の心はさまよう傾向があります。これは、スペースなしで文章を読むようなものです。

個人的には、メソッド内の単語はできるだけ少なくすることを好みます。パッケージとクラス名が意味を伝えることができるなら、あなたは助けられます。クラスの責任が非常に簡潔である場合、巨大なメソッド名は必要ありません。そこに "WithinTransaction"がある理由に興味があります。

「getNumberOfSkinCareEligibleItemsWithinTransaction」は次のようになります。

com.mycompany.app.product.SkinCareQuery.getNumEligibleItems（）;

使用中の場合、メソッドは「query.getNumEligibleItems（）」のようになります。

変数名が長すぎると、短い名前でプログラム全体またはプログラムの重要な部分のコードが読みやすくなります。

長い名前を使用すると、値に関するより多くの情報を伝えることができます。ただし、名前が長すぎると、コードが煩雑になり、残りのコードを理解する能力が低下します。これは通常、行を折り返し、他のコード行をページから押し出すことによって発生します。

秘訣は、どちらがより読みやすくなるかを決定することです。変数が頻繁に、または短いスペースで数回使用される場合は、短い名前を付けて、コメントを明確にすることをお勧めします。読者はコメントを簡単に参照できます。変数がプログラム全体で頻繁に使用される場合、多くの場合パラメーターとして、または他の複雑な操作で使用される場合、名前を削減するか、または頭字語を読者へのリマインダーとして使用するのが最善です。意味を忘れた場合、変数宣言によってコメントを参照できます。

これは、コードリーダーが理解しようとしている可能性が高いことを考慮し、コードが時間とともにどのように変化して成長するかを考慮する必要があるため、簡単にトレードオフすることはできません。だからこそ、物事に名前を付けるのは難しい。

DescriptiveLoopCounterNameの代わりにiをループカウンターとして使用することが許容される理由は、読みやすさです。これは変数の最も一般的な使用法であるため、画面スペースを最小限にして、その存在理由を説明できます。長い名前は、ループ条件をテストしたり、配列にインデックスを付けたりする方法を理解するのを難しくして、時間を浪費するだけです。

逆に、マルチパラメーター関数呼び出しに渡されるなど、複雑な操作のように関数または変数がほとんど使用されない場合は、過度に説明的な名前を付けることができます。

他の言語と同じように：関数が実行する単一のアクションを説明しなくなった場合。

私は良い答えの組み合わせを使用し、合理的だと思います。

メソッドが何をするかを完全に、明確に、そして読みやすく説明します。

メソッド名が長すぎると思われる場合は、メソッドのリファクタリングを減らしてください。

メソッドの名前が別の行に折り返され、メソッドへの呼び出しがその行で唯一のものであり、マージンのかなり近くで始まる場合は、長すぎます。使用する人の画面の平均サイズを考慮する必要があります。

だが！名前が長すぎると思われる場合は、おそらく長すぎます。それを回避する方法は、コンテキスト内にあり、名前は短いが他のコンテキストでは重複するようにコードを記述することです。これは、誰かのフルネームの代わりに「彼女」または「彼」を英語で言うことができるようなものです。

何が何であるかを言葉で説明しすぎると長すぎます。

たとえば、これらの名前は機能的に同等です。

Java： java.sql.SQLIntegrityConstraintViolationException

Python / Djangoの場合： django.db.IntegrityError

SQL / dbパッケージで、いくつのタイプの整合性エラーを思い付くことができるか自問してみてください。;）したがってdb.IntegrityError、十分です。

Javaコンパイラーが処理できる長さを超えるID名は長すぎます。

ここには2つの方法または観点があります。1つは、メソッドが何をしているかを説明するために可能な限り説明的な名前である限り、メソッド名の長さは実際には問題ではないということです（Javaベストプラクティスの基本ルール）。一方、flybywireの投稿には同意します。インテリジェンスを使用して、メソッド名をできるだけ減らすようにする必要がありますが、説明は減らしません。説明性はより重要です:)

名前が長すぎる場合：

• 読むのに1秒以上かかる
• JVMに割り当てるよりも多くのRAMを使用します
• 不条理な名前が付けられています
• 短い名前が完全に理にかなっている場合
• IDEで循環する場合

正直なところ、この名前は、目的をパブリックAPIメソッドとして利用する開発者に伝えるか、離れるときにコードを維持する必要があるだけです。ただKISSを覚えておいてください（単純な愚かさを保ちます）