Javaでは、パラメータとローカルに「最終」を使用する必要はありますか？

Javaでは、変数（フィールド/ローカル/パラメーター）をとしてマークしてfinal、それらへの再割り当てを防ぐことができます。一部の属性（またはクラス全体）が不変であるべきかどうかをすばやく確認できるので、フィールドで非常に便利です。

一方、ローカルおよびパラメーターではあまり役に立たないことがわかり、通常final、それらが再割り当てされないようにマークすることは避けます（内部クラスで使用する必要がある場合は明らかな例外があります） 。しかし、最近では、できる限りfinalを使用するコードに出会いました。これは技術的に詳細な情報を提供していると思います。

プログラミングスタイルに自信がなくなったので、finalどこにでも適用することのその他の長所と短所は何か、最も一般的な業界スタイルは何か、そしてその理由は何だろう。

私はfinalあなたと同じ方法を使用します。私にとっては、ローカル変数とメソッドのパラメーターは不要に見え、有用な追加情報を伝えません。

1つの重要なことは、メソッドを短く簡潔に保ち、それぞれが1つのタスクを実行するよう努めることです。したがって、ローカル変数とパラメーターのスコープは非常に限定されており、1つの目的にのみ使用されます。これにより、それらを不注意に再割り当てする可能性が最小限に抑えられます。

さらに、ご存じのとおり、final（非プリミティブ）変数の値/状態を変更できないことを保証しません。一度初期化すると、そのオブジェクトへの参照を再割り当てできません。つまり、プリミティブ型または不変型の変数でのみシームレスに機能します。検討する

final String s = "forever";
final int i = 1;
final Map<String, Integer> m = new HashMap<String, Integer>();

s = "never"; // compilation error!
i++; // compilation error!
m.put(s, i); // fine

これは、多くの場合、コード内で何が起こっているのかを理解しやすくしないことを意味し、これを誤解すると、実際には検出しにくい微妙なバグが発生する可能性があります。

Javaプログラミングのスタイルと考え方は問題ありません。自分自身を疑う必要はありません。

一方、ローカルおよびパラメーターではあまり役に立たず、通常、それらが再割り当てされない場合でも最終としてマークすることは避けます（内部クラスで使用する必要がある場合は明らかな例外があります） ）。

これがまさにfinalキーワードを使用すべき理由です。あなたは、あなたはそれが決して再割り当てされることはないと知っているが、他の誰もそれを知らないことを述べる。finalすぐに使用すると、コードの曖昧さが解消されます。

final/をconst可能な限り使用することの1つの利点は、コードの読者の精神的な負担を軽減することです。

値/参照が後で変更されることはないので、彼は安心できます。そのため、計算を理解するために変更に注意を払う必要はありません。

純粋に機能的なプログラミング言語を学んだ後、私はこれに関して私の考えを変えました。「変数」が常に初期値を保持することを信頼できるなら、なんてほっとするでしょう。

finalメソッドのパラメーターとローカル変数では、コードノイズと見なします。Javaメソッドの宣言は非常に長くなる可能性があります（特にジェネリックの場合）-もう宣言する必要はありません。

単体テストが適切に記述されている場合、「有害」なパラメータへの割り当てが選択されるため、実際に問題になることはありません。ユニットテストのカバレッジが不十分であるため、検出されない可能性のあるバグを回避するよりも、視覚的な明瞭さが重要です。

FindBugsやCheckStyleのようなツールは、パラメーターやローカル変数に割り当てが行われた場合にビルドを中断するように構成できます。そのようなことを深く気にかけている場合。

もちろん、たとえば匿名クラスで値を使用しているなどの理由で、それらを最終的にする必要がある場合は、問題ありません。これが最も簡単でクリーンなソリューションです。

パラメータに余分なキーワードを追加し、それによってそれらを偽装するという明らかな効果とは別に、メソッドパラメータにfinalを追加すると、メソッド本体のコードが読みにくくなり、コードが悪化します-「良い」コードできるだけ読みやすく、シンプルでなければなりません。不自然な例として、大文字と小文字を区別せずに動作させる必要があるメソッドがあるとします。

なしfinal：

public void doSomething(String input) {
    input = input.toLowerCase();
    // do a few things with input
}

シンプル。掃除。誰もが何が起こっているかを知っています。

「最終」オプション1を使用します。

public void doSomething(final String input) {
    final String lowercaseInput = input.toLowerCase();
    // do a few things with lowercaseInput
}

パラメータを作ることながら、finalさらに下に、彼は元の値での作業の思考からのコードを追加することコーダを停止し、さらに下にそのコードを使用することができます等しい危険がありますinput代わりにlowercaseInput、それはやから保護することができないべきではない、「ので、あなたがすることができ、 tはスコープの外にそれを取る（あるいは割り当てるnullにinputそれでもとにかく助けになる場合）。

「最終」オプション2の場合：

public void doSomething(final String input) {
    // do a few things with input.toLowerCase()
}

これで、さらに多くのコードノイズが作成され、toLowerCase()n回呼び出す必要があるというパフォーマンスヒットが発生しました。

「最終」、オプション3の場合：

public void doSomething(final String input) {
    doSomethingPrivate(input.toLowerCase());
}

/** @throws IllegalArgumentException if input not all lower case */
private void doSomethingPrivate(final String input) {
    if (!input.equals(input.toLowerCase())) {
        throw new IllegalArgumentException("input not lowercase");
    }
    // do a few things with input
}

コードノイズについて話します。これは列車事故です。他のコードが誤って呼び出す可能性があるため、必要な例外ブロックという新しいメソッドがあります。例外をカバーするためのより多くの単体テスト。すべてが1つの単純な、そして私見が望ましい無害なラインを避けるために。

また、メソッドを視覚的に簡単に取り入れることができず、パラメーターへの割り当てが行われたことを一目で知ることができないほど、メソッドを長くすべきではないという問題もあります。

私はそれはあなたがそれを行うパラメータに割り当てた場合、好ましくは最初の行またはストレート基本的な入力チェックの後、この方法では、すべての初期のが効果的という良い習慣/スタイルだと思いますか交換のためにそれを全体の中に一貫性のある効果を持っている方法で、方法。読者は、割り当てが明白（署名宣言の近く）で一貫した場所にあることを期待していることを知っています。実際、パラメーターに割り当てることはめったにありませんが、そうする場合は常にメソッドの最上部で行います。

また、final実際には保護されていないことに注意してください。

public void foo(final Date date) {
    date.setTime(0); 
    // code that uses date
}

final パラメータタイプがプリミティブまたは不変でない限り、完全に保護されません。

finalプログラムを読みやすくするために、Eclipseを各ローカル変数の前に置いています。パラメーターリストはできるだけ短くしたいので、パラメーターで作成しません。理想的には1行に収まるようにします。