これらのPMDルールの理由は何ですか？
DataflowAnomalyAnalysis：変数 'variable'の 'DD'-anomalyが見つかりました（行' n1 '-' n2 '）。
DataflowAnomalyAnalysis：変数 'variable'の 'DU'-anomalyが見つかりました（行' n1 '-' n2 '）。
DDとDUはおなじみのように聞こえます...最も弱い事前条件と事後条件に関連するテストや分析などについて言いたいのですが、具体的なことは覚えていません。
NullAssignment：オブジェクトをnullに割り当てると、コードのにおいがします。リファクタリングを検討してください。
オブジェクトがローカルオブジェクト（メソッドの外では使用されない）である場合、オブジェクトをnullアシストにガベージコレクションで設定しませんか？それとも神話ですか？
MethodArgumentCouldBeFinal：パラメータ 'param'は割り当てられておらず、finalと宣言できます
LocalVariableCouldBeFinal：ローカル変数 'variable'はfinalと宣言できます
finalパラメータと変数を使用する利点はありますか？
LooseCoupling： 'LinkedList'のような実装タイプの使用は避けてください。代わりにインターフェースを使用してください
LinkedListが特に必要であることがわかっている場合、将来の開発者に明確に意図を伝えるためにこれを使用しないのはなぜですか？意味のあるクラスパスの一番上にあるクラスを返すことは1つですが、なぜ変数を最も厳密な意味を持つものとして宣言しないのですか？
AvoidSynchronizedAtMethodLevel：メソッドレベルの同期ではなくブロックレベルを使用
ブロックレベルの同期には、メソッドレベルの同期と比べてどのような利点がありますか？
AvoidUsingShortType：short型を使用しないでください
私の最初の言語はCとC++でしたが、Java=の世界では、データを最もよく表すタイプを使用しないのはなぜですか？
DDとDUの異常（私が正しく覚えている場合-私はFindBugsを使用し、メッセージが少し異なる）は、通常、読み込まれる前に別の値が再割り当てされるため、読み込まれないローカル変数に値を割り当てることを指します。典型的なケースは、変数が宣言されたときに
nullで変数を初期化することです。 必要になるまで変数を宣言しないでください。ガベージコレクターを「支援」するために
nullをローカル変数に割り当てることは神話です。 PMDは、これが非生産的な混乱であることを通知しています。ローカル変数にfinalを指定するshouldは、オプティマイザにとって非常に役立ちますが、このヒントを利用した現在のJITの具体的な例はありません。私は自分のコードの正しさを推論するのに役立つことがわかりました。
interfacesの観点からインターフェイスを指定することは、優れた設計手法です。呼び出し元にまったく影響を与えることなく、コレクションの実装を簡単に変更できます。それがインターフェースのすべてです。
呼び出し側が
LinkedListをrequire要求する多くのケースは考えられません。いくつかのインターフェースで宣言されています。クライアントがそのAPIに依存している場合は、適切なインターフェースを介して使用できます。ブロックレベルの同期により、クリティカルセクションを小さくできるため、可能な限り多くの作業を同時に実行できます。おそらくより重要なのは、それを囲んでいるオブジェクトによってプライベートに制御されるロックオブジェクトの使用を許可することです。これにより、デッドロックが発生しないことを保証できます。インスタンス自体をロックとして使用すると、だれでも誤ってインスタンスを同期し、デッドロックを引き起こす可能性があります。
タイプ
shortのオペランドは、どの操作でもintに昇格されます。このルールは、このプロモーションが発生していることを通知しており、intを使用することもできます。ただし、shortタイプを使用するとメモリを節約できるため、インスタンスメンバーである場合は、おそらくそのルールを無視します。
finalの質問に関するメモです。
変数に「最終」を置くと、割り当て可能になるのはonceだけになります。これは必ずしも書きやすいことを意味するわけではありませんが、将来のメンテナにとってreadのほうが簡単であることは間違いありません。
次の点を考慮してください。
finalを含む変数は、「監視中に値を変更しない」にすぐに分類できます。- つまり、変更されないすべての変数がfinalでマークされている場合、finalでマークされていない変数は実際に変更されます。
これは、コードの中で値を変更する可能性があるため、どの変数を探すべきかを定義部分を読んでいるときにすでに確認できることを意味します。コードが読みやすくなると、メンテナーは努力をよりよく費やすことができます。
DataflowAnomalyAnalysis：変数 'variable'の 'DD'-anomalyが見つかりました（行' n1 '-' n2 '）。
DataflowAnomalyAnalysis：変数 'variable'の 'DU'-anomalyが見つかりました（行' n1 '-' n2 '）。
わからない.
NullAssignment：オブジェクトをnullに割り当てると、コードのにおいがします。リファクタリングを検討してください。
オブジェクトがローカルオブジェクト（メソッドの外では使用されない）の場合、ガベージコレクションで
nullアシストにオブジェクトを設定しませんか？それとも神話ですか？
ローカルメソッドのオブジェクトは、メソッドが戻るとガベージコレクションの対象としてマークされます。それらをnullに設定しても、違いはありません。
それは開発者の経験を少なくするので、それに関するすべてのnull割り当てはコードのにおいと見なされるかもしれません。
MethodArgumentCouldBeFinal：パラメータ 'param'は割り当てられておらず、finalと宣言できます
LocalVariableCouldBeFinal：ローカル変数 'variable'はfinalと宣言できます
finalパラメータと変数を使用する利点はありますか？
これにより、オブジェクトのライフサイクル中に値が変化しないことが明確になります。
また、万が一誰かが値を割り当てようとした場合、コンパイラはコンパイルタイプでこのコーディングエラーを防ぎます。
このことを考慮：
public void businessRule( SomeImportantArgument important ) {
if( important.xyz() ){
doXyz();
}
// some fuzzy logic here
important = new NotSoImportant();
// add for/if's/while etc
if( important.abc() ){ // <-- bug
burnTheHouse();
}
}
あなたが時々家を焼くいくつかの神秘的なバグを解決するために割り当てられているとします。
使用されたパラメーターが何でしたか、理解できないものは[〜＃〜] why [〜＃〜]条件が満たされない場合にburnTHeHouseメソッドが呼び出されます（結果によると）
途中のある時点でsomoneが参照を変更し、otherオブジェクト。
finalのヘルプを使用すると、このようなことを防ぐことができます。
LooseCoupling： 'LinkedList'のような実装タイプの使用は避けてください。代わりにインターフェースを使用してください
LinkedListが特に必要であることがわかっている場合、将来の開発者に意図を明確に示すためにこれを使用しないのはなぜですか？意味のあるクラスパスの最も上にあるクラスを返すことは1つですが、なぜ変数を最も厳密な意味であると宣言しないのですか？
この場合、違いはありません。 LinkedList固有の機能を使用していないので、提案は公平だと思います。
今日、LinkedListは理にかなっているかもしれませんが、インターフェースを使用することで、自分（または他の人）が変更できないときに簡単に変更できるようにします。
小規模な個人プロジェクトの場合、これはまったく意味がありませんが、既にアナライザーを使用しているので、コードの品質はすでに気になっていると思います。
また、経験の浅い開発者が良い習慣を作るのに役立ちます。 [あなたが1人だと言っているわけではありませんが、分析者はあなたを知りません;）]
AvoidSynchronizedAtMethodLevel：メソッドレベルの同期ではなくブロックレベルを使用
ブロックレベルの同期には、メソッドレベルの同期に比べてどのような利点がありますか？
同期セクションが小さいほど良いです。それでおしまい。
また、メソッドレベルで同期すると、オブジェクト全体がブロックされます。ブロックレベルで同期するときは、特定のセクションを同期するだけですが、状況によってはそれが必要な場合もあります。
AvoidUsingShortType：short型を使用しないでください
私の最初の言語はCとC++でしたが、Javaの世界では、自分のデータを最もよく表すタイプを使用しないのはなぜですか？
私はこれについて聞いたことがなく、私もあなたに同意します:)私はショートを使ったことはありません。
私の推測では、これを使用しないことで、シームレスにintにアップグレードできるようになります。
コードの匂いは、パフォーマンスの最適化よりもコードの品質を重視しています。したがって、アドバイスは、プログラムの速度を改善するよりも、経験の浅いプログラマーに、落とし穴を避けるために与えられます。
このようにして、より良い設計に適合するようにコードを変更しようとするときに、多くの時間とフラストレーションを節約できます。
アドバイスが意味をなさない場合は、無視してください。あなたは担当の開発者であり、ツールは単なるツールです。何か問題が発生した場合、ツールのせいにできませんよね？
オブジェクトがローカルオブジェクト（メソッドの外では使用されない）の場合、オブジェクトをnullに設定してガベージコレクションを支援しませんか？それとも神話ですか？
それが行う唯一のことは、メソッドが終了する前にオブジェクトをGCdできるようにすることです。これはめったに必要ではありません。
最終的なパラメーターと変数を使用する利点はありますか？
コードを分析するときに値が変更されることを心配する必要がないため、コードがいくらか明確になります。多くの場合、一度設定した変数の値を変更する必要はありません。
LinkedListが特に必要であるとわかっている場合、将来の開発者に意図を明確に示すために使用しないのはなぜですか？
LinkedListが特に必要になる理由を考えられますか？
意味のあるクラスパスの一番上にあるクラスを返すことは1つですが、なぜ変数を最も厳密な意味を持つものとして宣言しないのですか？
ローカル変数やフィールドについてはあまり気にしていませんが、LinkedList型のメソッドパラメータを宣言すると、Arrays.asList()やCollections.emptyList()。
ブロックレベルの同期には、メソッドレベルの同期と比べてどのような利点がありますか？
最大のものは、同じモニターを使用するすべてのものではなく、専用のモニターオブジェクトを使用して、重要なセクションだけを相互に排他的にできるようにすることです。
Javaの世界では、自分のデータを最もよく表すタイプを使用しないのはなぜですか？
なぜなら、intよりも小さい型は、すべての計算で自動的にintに昇格され、それらに何かを割り当てるにはキャストダウンする必要があるからです。これにより、コードが乱雑になり、かなりの混乱が生じます（特にオートボクシングが関係する場合）。
AvoidUsingShortType：short型を使用しないでください
リストアイテム
shortは16ビット、Javaでは2の賛辞
- integerファミリーの別のshortの外側にあるものを含む短い数学演算では、実行時の符号拡張をより大きなサイズに変換する必要があります。浮動小数点に対して動作するには、符号拡張とIEEE-754への自明でない変換が必要です。
- 証拠を見つけることができませんが、32ビットまたは64ビットのレジスタを使用すると、バイトコードレベルでの「プロセッサ命令」を節約できなくなります。プロセッサーのレジスターに関する限り、セミトレーラーの駐車スペースにコンパクトカーを駐車しています。
- あなたがバイトコードレベルでプロジェクトを最適化しているなら、すごい。すごい。 ; P
- 私はこのpmd警告を無視するという設計側に同意します。発生するパフォーマンス変換に対して「短い」オブジェクトでオブジェクトを正確に説明するだけです。
- 私の意見では、発生するパフォーマンスヒットはほとんどのマシンでごくわずかです。エラーを無視します。
ブロックレベルの同期には、メソッドレベルの同期と比べてどのような利点がありますか？メソッドの同期は、
synchronize(getClass())ブロックのようなもので、すべてのクラスをブロックします。
多分あなたはそれを望まない