重複の可能性：
いつfinalを使用する必要がありますか？
必要な場合を除いて、すべての変数を宣言する傾向がありますfinal。これは、識別子が期待どおりに使用されていることをコンパイラーがチェックできるため（たとえば、変更されていない）、これは良い習慣だと思います。一方、それはコードを乱雑にし、おそらくこれは「Javaの方法」ではありません。
最終変数の不要な使用に関して一般的に受け入れられているベストプラクティスがあるかどうか、およびこの議論に知っておくべき他のトレードオフまたは側面があるかどうか疑問に思います。
「Java 方式」は本質的に雑然としています。
私はそれが良い習慣だと言いますが、私が従うものではありません。
テストは通常、意図したことを行っていることを確認しますが、私の美学には雑然としすぎています。
私は定期的finalにコード内のローカル変数に適用し、さらに、最初にすべての効果的な最終変数をキーワードでマークした後、コードを読むのがはるかに簡単になることに気付きました。私はこれをコードの正真正銘の拡張と見なし、その後すぐにコミットします。final
コードが乱雑になることについては、ローカル変数に適用しても問題はないと思います。実際、構文の色付けにより、すべての宣言をより簡単に見つけることができます。
ただし、 をパラメーター、キャッチ ブロック、拡張 for ループ、および狭義のローカル変数以外のすべての場所で使用すると、耐えられないほど雑然としていることを認めなければなりません。finalこのような場合の再割り当てはさらに混乱を招き、デフォルトで実際には最終的なものになっているはずなので、これは非常に残念です。
コンパイラーよりも保守プログラマー (私を含む!) にとって良い習慣だと思います。メソッド内でどの変数が変更されているかを気にする必要がなければ、メソッドについて考えるのは簡単です。
オブジェクトの構築時にどのフィールドを指定する必要があるかが明確に示されているためです。
それが「コードの乱雑さ」を生み出すことに私は強く反対します。それは言語の優れた強力な側面です。
設計原則として、可能であればクラスを不変(すべての final フィールド) にする必要があります。これは、クラスを安全に公開できる (つまり、破損する恐れなく自由にやり取りできる) ためです。ただし、フィールド自体も不変オブジェクトである必要があることに注意してください。
それは間違いなくより良いコードを提供し、どのすべての変数が変更されるかを簡単に確認できます。
また、変更しないことをコンパイラに通知するため、最適化が向上します。
それに加えて、間違いを犯しがちな場合は、IDE がコンパイル時に通知することができます。
PMD などのいくつかの優れた分析ツールは、final必要でない限り常に配置するようにアドバイスします。したがって、そのツールの慣習は、それが良い習慣であると言っています
しかし、コード内の最終的なトークンが非常に多いと、人間に優しくなくなる可能性があると思います.
はい、コンパイラの最適化ではなく、読みやすさのためです。
でも個人的には使っていません。Java自体は非常に冗長であり、「グッドプラクティス」と見なされるすべてに従うと、コードはすべての定型文から赤字化できなくなります。しかし、それは好みの問題です。
メリットとデメリットをまとめてみました...
別の短所を追加できます：
コードの読者は、final 変数の値について推論する必要はまったくありません (まれな悪いコードのケースを除きます)。
だから、はい、それは良い習慣です。
そして、あなたがそれに慣れた後は、混乱はそれほど悪くありません（unix :-Pのように）。さらに、典型的な IDE は自動的にそれを行います...