質問
DataflowAnomalyAnalysis:見つかりました 'DD'-変数 'variable'の異常 ( 'n1'-'n2'行)。
DataflowAnomalyAnalysis:見つかりました 'DU'-変数 'variable'の異常 ( 'n1'-'n2'行)。
DDとDUはおなじみのようです...テストや分析など、最も弱い事前条件と事後条件に関することを言いたいのですが、詳細は覚えていません。
NullAssignment:オブジェクトの割り当て nullはコードの匂いです。検討する リファクタリング。
オブジェクトが null
に設定されていないと、オブジェクトがローカルオブジェクト(メソッドの外部で使用されていない)である場合、ガベージコレクションに役立ちませんか?それとも神話ですか?
MethodArgumentCouldBeFinal:パラメーター 「param」は割り当てられておらず、 最終宣言
LocalVariableCouldBeFinal:ローカル 変数 'variable'を宣言できます 最終
final
パラメータと変数を使用する利点はありますか?
LooseCoupling:使用を避ける 実装タイプ 'LinkedList';インターフェースを使用する 代わりに
特に LinkedList
が必要であることがわかっている場合、将来の開発者に自分の意図を明確に示すためにそれを使用しないのはなぜですか?意味のあるクラスパスの最上位にあるクラスを返すことは1つのことですが、なぜ変数を最も厳密な意味で宣言しないのですか?
AvoidSynchronizedAtMethodLevel:使用 メソッドレベルではなくブロックレベル 同期
ブロックレベルの同期は、メソッドレベルの同期よりも優れていますか
AvoidUsingShortType:は使用しないでください ショートタイプ
最初の言語はCとC ++でしたが、Javaの世界では、データを最もよく説明する型を使用しないのはなぜですか?
解決
-
DDおよびDUの異常(正しく覚えている場合— FindBugsを使用し、メッセージが少し異なる)は、通常は別の値が再割り当てされるため、読み取られないローカル変数に値を割り当てることを参照読まれる前に。典型的なケースは、変数が宣言されたときに
null
で初期化することです。 必要になるまで変数を宣言しないでください。 -
ローカル変数に
null
を割り当てて「アシスト」する;ガベージコレクターは神話です。 PMDは、これが単に非生産的な混乱であることをあなたに知らせています。 -
ローカル変数にfinalを指定することはオプティマイザーにとって非常に便利です が、このヒントを利用する現在のJITの具体的な例はありません。私は自分のコードの正確さについて推論するのに役立つことがわかりました。
-
インターフェースの指定について…まあ、インターフェースは優れた設計手法です。呼び出し側にまったく影響を与えることなく、コレクションの実装を簡単に変更できます。これがインターフェースのすべてです。
-
呼び出し元が
LinkedList
を必要とする多くのケースは考えられません。なぜなら、それによって宣言されていないAPIを公開しないからです。インターフェース。クライアントがそのAPIに依存している場合、正しいインターフェースから利用できます。 -
ブロックレベルの同期により、クリティカルセクションを小さくできるため、できるだけ多くの作業を同時に実行できます。おそらくもっと重要なのは、それが囲んでいるオブジェクトによってプライベートに制御されるロックオブジェクトの使用を許可することです。これにより、デッドロックが発生しないことを保証できます。インスタンス自体をロックとして使用すると、だれでもそれを誤って同期でき、デッドロックが発生します。
-
タイプ
short
のオペランドは、すべての操作でint
に昇格されます。このルールは、このプロモーションが行われていることをユーザーに知らせるものであり、int
を使用することもできます。ただし、short
タイプを使用するとメモリを節約できるため、インスタンスメンバーの場合は、おそらくこのルールを無視します。
他のヒント
DataflowAnomalyAnalysis:見つかりました 'DD'-変数 'variable'の異常 ( 'n1'-'n2'行)。
DataflowAnomalyAnalysis:見つかりました 'DU'-変数 'variable'の異常 ( 'n1'-'n2'行)。
わからない。
NullAssignment:オブジェクトの割り当て nullはコードの匂いです。検討する リファクタリング。
オブジェクトが
null
に設定されていないと、オブジェクトがローカルオブジェクト(メソッドの外部で使用されていない)である場合、ガベージコレクションに役立ちませんか?それとも神話ですか?
ローカルメソッドのオブジェクトは、メソッドが戻るとガベージコレクションとしてマークされます。それらをnullに設定しても違いはありません。
開発者の経験が少なくなるので、それに関するすべてのnull割り当てはコードにおいと見なされる可能性があります。
MethodArgumentCouldBeFinal:パラメーター 「param」は割り当てられておらず、 最終宣言
LocalVariableCouldBeFinal:ローカル 変数 'variable'を宣言できます 最終
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();
}
}
あなたが時々家を焼くいくつかの神秘的なバグを解決するために割り当てられているとします。
使用されたパラメーターが何であるかがわかります。理解できないのは、理由です(条件が満たされない場合に burnTHeHouse
メソッドが呼び出されます)。
途中のある時点で somone が参照を変更し、 other オブジェクトを使用していることを見つけるのに時間がかかります。
final
を使用すると、このような事態を防ぐことができます。
LooseCoupling:使用を避ける 実装タイプ 'LinkedList';インターフェースを使用する 代わりに
LinkedList
が特に必要であることがわかっている場合、将来の開発者に対して明確に意図を明確にするためにそれを使用しないのはなぜですか?意味のあるクラスパスの最上位にあるクラスを返すのは1つのことですが、なぜ変数を最も厳密な意味で宣言しないのですか?
この場合、違いはありません。 LinkedList
固有の機能を使用していないので、提案は公平だと思います。
今日、LinkedListは理にかなっているかもしれませんが、インターフェイスを使用することで、自分(または他の人)が簡単に変更できるようにします。
小規模で個人的なプロジェクトの場合、これはまったく意味をなさないかもしれませんが、すでにアナライザーを使用しているので、コードの品質をすでに気にしていると思います。
また、経験の浅い開発者が良い習慣を作るのを助けます。 [私はあなたが1人であると言っているわけではありませんが、分析装置はあなたを知りません;)]
AvoidSynchronizedAtMethodLevel:使用 メソッドレベルではなくブロックレベル 同期
ブロックレベルの同期には、メソッドレベルの同期と比べてどのような利点がありますか?
同期セクションが小さいほど良い。それだけです。
また、メソッドレベルで同期すると、オブジェクト全体がブロックされます。ブロックレベルで同期する場合、特定の状況を同期するだけで、状況によっては必要な場合もあります。
AvoidUsingShortType:は使用しないでください ショートタイプ
最初の言語はCとC ++でしたが、Javaの世界では、自分のデータを最もよく表す型を使用しないのはなぜですか?
これについて聞いたことがありませんし、あなたに同意します:)
私の推測では、それを使用しないことで、あなたの自己のアップグレードを助けているでしょう。
final
質問に注意してください。
「最終」を置く変数の結果は、 1回のみ割り当て可能です。これは必ずしも簡単に書けることを意味するわけではありませんが、将来のメンテナーにとって読むの方が簡単であることを最も確実に意味します。
これらの点を考慮してください:
-
final
を持つ変数は、すぐに「視聴中に値を変更しない」に分類できます。 - 含意により、変更されないすべての変数がfinalでマークされている場合、finalでマークされていない変数は実際に変更されます。
これは、コード内で値が変更される可能性があるため、どの変数に注目するかを定義部分を読むときにすでに確認できることを意味し、メンテナーはコードが読みやすいほど努力を費やすことができます。
オブジェクトをnullに設定しませんでした ガベージコレクションを支援する場合、 オブジェクトはローカルオブジェクトです(使用されません) メソッドの外)?それとも 神話?
唯一のことは、メソッドの終了前にオブジェクトをGCできるようにすることです。これはめったに必要ではありません。
最終的なパラメーターと変数を使用する利点はありますか
コードを分析するときに、どこで値が変更されるかを心配する必要がないため、コードがいくらか明確になります。多くの場合、変数の値を設定する必要はありませんし、変更する必要もありません。
特に必要なことがわかっている場合 LinkedList、なぜ私はそれを使用しないのですか? 私の意図を明確に明確にする 将来の開発者?
特に必要な理由を考えてください LinkedList?
それは一つのことです 最高のクラスを返します 意味のあるクラスパス、しかしなぜ 変数を次のように宣言しませんか 厳密な意味ですか?
ローカル変数やフィールドについてはあまり気にしませんが、 LinkedList
型のメソッドパラメーターを宣言すると、あなたを追い詰めて傷つけます。 Arrays.asList()
や Collections.emptyList()
などを使用します。
ブロックレベルの同期には、メソッドレベルの同期と比べてどのような利点がありますか?
最大のものは、同じモニターを使用するすべてではなく、必要なクリティカルセクションのみが相互に排他的となるように、専用モニターオブジェクトを使用できることです。
Javaの世界では、なぜそうすべきではないのか 私を最もよく説明するタイプを使用してください データ?
すべての計算でintより小さい型は自動的にintに昇格されるため、それらに型を割り当てるにはキャストダウンする必要があります。これにより、コードが乱雑になり、かなりの混乱を招きます(特にオートボクシングが関係する場合)。
AvoidUsingShortType:短い型を使用しないでください
-
リストアイテム
shortは16ビット、javaの2の賛辞
- 別のshort以外のIntegerファミリーに含まれる数学的操作では、実行時符号拡張をより大きなサイズに変換する必要があります。浮動小数点に対して動作するには、符号拡張とIEEE-754への非自明な変換が必要です。
- 証明は見つかりませんが、32ビットまたは64ビットのレジスタを使用すると、バイトコードレベルで「プロセッサ命令」を節約できなくなります。プロセッサのレジスタに関する限り、セミトレーラーの駐車場にコンパクトカーを駐車しています。
- バイトコードレベルでプロジェクトを最適化する場合は、すごいです。ただすごい。 ; P
- このpmd警告を無視するというデザイン側に同意します。「短い」対発生したパフォーマンス変換でオブジェクトを正確に記述します。
- 私の意見では、ほとんどのマシンで発生するパフォーマンスの低下はごくわずかです。エラーを無視します。
ブロックレベルの利点 同期はメソッドレベルを超えています 同期? メソッドの同期は、
synchronize(getClass())
ブロックを実行し、すべてのクラスをブロックするようなものです。
たぶんあなたはそれを望まないでしょう