たとえば、AndroidでCPUをオンに保つには、次のようなコードを使用できます。

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();

しかし、私はローカル変数powerManagerと考えるwakeLockことができます：

((PowerManager)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
    .acquire();

同様のシーンがiOSアラートビューに表示されます。例：from

UIAlertView *alert = [[UIAlertView alloc]
    initWithTitle:@"my title"
    message:@"my message"
    delegate:nil
    cancelButtonTitle:@"ok"
    otherButtonTitles:nil];
[alert show];

-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex{
    [alertView release];
}

に：

[[[UIAlertView alloc]
    initWithTitle:@"my title"
    message:@"my message"
    delegate:nil
    cancelButtonTitle:@"ok"
    otherButtonTitles:nil] show];

-(void)alertView:(UIAlertView *)alertView clickedButtonAtIndex:(NSInteger)buttonIndex{
    [alertView release];
}

スコープ内で一度だけ使用される場合、ローカル変数を削除するのは良い習慣ですか？

コードは書かれているよりもはるかに頻繁に読まれるので、6か月後（あなたかもしれません）にコードを読まなければならない貧しい人の魂に同情し、最も明確で理解しやすいコードを目指して努力する必要があります。私の意見では、ローカル変数を使用した最初の形式の方がはるかに理解しやすいです。1行に3つのアクションではなく、3行に3つのアクションが表示されます。

そして、ローカル変数を取り除くことで何かを最適化していると思うなら、そうではありません。最新のコンパイラーは、ローカル変数を使用するかどうかにかかわらず、メソッドを呼び出すためにpowerManagerレジスター^1に入れnewWakeLockます。同じことはにも当てはまりますwakeLock。したがって、どちらの場合も同じコンパイル済みコードになります。

¹宣言とローカル変数の使用との間に多くのコードが介在している場合、スタックに置かれる可能性がありますが、それは細部ではありません。

いくつかの非常に支持されたコメントがこれを述べましたが、私が見た答えはどれもなかったので、答えとして追加します。この問題を決定する主な要因は次のとおりです。

デバッグ可能性

多くの場合、開発者はコードを書くよりもはるかに多くの時間と労力を費やします。

ローカル変数、次のことができます。

• 割り当てられている行のブレークポイント（条件付きブレークポイントなど、他のすべてのブレークポイントの装飾を含む）

• ローカル変数の値の検査/監視/印刷/変更

• キャストが原因で発生する問題をキャッチします。

• 読みやすいスタックトレースを使用します（行XYZには10ではなく1つの操作があります）

ローカル変数がなければ、上記のタスクはすべて、デバッガーに応じて、はるかに難しい、非常に難しい、またはまったく不可能です。

そのため、悪名高い格言（次の開発者が自分の住んでいる場所を知っている狂った狂人であるかのようにコードを書いてください）に従い、デバッグを容易にするために、ローカル変数を使用することを意味します。

コードが理解しやすくなる場合のみ。あなたの例では、読みにくくなると思います。

コンパイルされたコード内の変数を削除することは、優れたコンパイラーにとって簡単な操作です。出力を自分で調べて確認できます。

あなたの質問は、「ローカル変数がスコープ内で一度だけ使用される場合、ローカル変数を削除することは良い習慣ですか？」間違った基準をテストしています。ローカル変数のユーティリティは、使用回数に依存するのではなく、コードを明確にするかどうかに依存します。意味のある名前で中間値にラベルを付けると、コードをより小さく、より消化しやすいチャンクに分解するため、あなたが提示するような状況で明確さを向上させることができます。

私の見解では、あなたが提示した変更されていないコードは、変更されたコードよりも明確であるため、変更しないでください。実際、わかりやすくするために、変更したコードからローカル変数を引き出すことを検討します。

ローカル変数によるパフォーマンスへの影響は期待していません。1つでも、プログラムの速度が重要な部分でコードが非常にタイトなループにある場合を除いて、検討する価値はありません。

多分。

個人的には、タイプキャストが関係する場合はローカル変数を削除することをためらうでしょう。ブラケットの数が私が持っている精神的な限界に近づき始めると、あなたのコンパクト版は読みにくくなります。さらに、ローカル変数を使用するもう少し冗長なバージョンでは必要なかった新しい括弧のセットを導入します。

コードエディタによって提供される構文の強調表示により、このような懸念がある程度緩和される可能性があります。

私の目には、これがより良い妥協点です。

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc").acquire();

したがって、1つのローカル変数を保持し、他のローカル変数を捨てます。C＃では、タイプキャストが既にタイプ情報を提供しているため、最初の行でvarキーワードを使用します。

ローカル変数を好む回答の妥当性を受け入れますが、悪魔の擁護者を演じ、逆説的な見解を提示します。

個人的には、文書化の目的だけでローカル変数を使用することに多少反対ですが、その理由自体は、プラクティスに価値があることを示しています。ローカル変数は、コードを効果的に擬似文書化します。

あなたの場合、主な問題はインデントであり、変数がないことです。次のようにコードをフォーマットできます（また、そうする必要があります）。

((PowerManager)getSystemService(POWER_SERVICE))
        .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"MyWakelockTag")
        .acquire();

ローカル変数を使用したバージョンと比較してください。

PowerManager powerManager=(PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"abc");
wakeLock.acquire();

ローカル変数を使用すると、名前によってリーダーに情報が追加され、タイプが明確に指定されますが、実際のメソッド呼び出しは見えにくくなり、（私の意見では）明確に読み取れません。

ローカル変数を使用しない場合：より簡潔でメソッド呼び出しがよりわかりやすくなりますが、返されるものについての詳細情報を要求する場合があります。ただし、一部のIDEではこれを表示できます。

さらに3つのコメント：

1. 私の意見では、機能的な用途のないコードを追加することは、混乱を招く場合があります。たとえば、このメソッドが100行の長さである場合、メソッド全体を読まない限り、ローカル変数（およびメソッド呼び出しの結果）が後の時点で不要になることは明らかではありません。

2. ローカル変数を追加すると、それらのタイプを指定する必要があり、そうしないとコードに依存関係が生じます。メソッドの戻り値の型が簡単に変更された場合（たとえば、名前が変更された場合）、コードを更新する必要がありますが、ローカル変数がない場合は変更しません。

3. デバッガがメソッドから返された値を表示しない場合、ローカル変数を使用するとデバッグが容易になります。しかし、その修正は、コードを変更するのではなく、デバッガーの欠陥を修正することです。

ここには動機の緊張があります。一時変数を導入すると、コードが読みやすくなります。ただし、メソッドの抽出や、TempをQueryに置き換えるなど、他のリファクタリングを防止したり、見にくくしたりすることもできます。これらの後者のタイプのリファクタリングは、必要に応じて、多くの場合、temp変数よりもはるかに大きな利点を提供します。

これらの後者のリファクタリングの動機について、ファウラーは次のように書いています。

「tempsの問題は、一時的でローカルなことです。使用されるメソッドのコンテキストでのみ表示されるため、tempsはtempに到達する唯一の方法であるため、より長いメソッドを推奨する傾向があります。 tempをクエリメソッドに置き換えると、クラス内のすべてのメソッドが情報を取得できます。これは、クラスのコードをよりきれいにするのに役立ちます。」

そのため、特にコードが読みやすくなる場合、特にそれがあなたとあなたのチームにとってローカルな規範である場合、tempsを使用します。ただし、そうすることで、より大きな代替の改善点を見つけるのが難しくなる場合があることに注意してください。そのような臨時雇用者なしで行く価値があるときに感じる能力を開発し、そうすることでより快適になることができれば、それはおそらく良いことです。

FWIW私は個人的にファウラーの本「リファクタリング」を読むことを10年間避けました。私は完全に間違っていました。最終的にそれを読んだとき、それは私の毎日のコーディング慣行を大きく変えました。

それにより、コードを読みやすくすることができる場合は、ローカル変数を削除することをお勧めします。あなたの長い一行は読めませんが、それからかなり冗長なオブジェクト指向スタイルに従います。のようなものに減らすことができれば

acquireWakeLock(POWER_SERVICE, PARTIAL, "abc");

それはおそらく良いアイデアだと思います。おそらく、ヘルパーメソッドを導入して、それを似たようなものに要約することができます。このようなコードが複数回現れる場合、それは価値があるかもしれません。

ここでデメテルの法則について考えてみましょう。LoDに関するウィキペディアの記事には、次のことが記載されています。

関数のDemeterの法則では、オブジェクトOのメソッドmは、次の種類のオブジェクトのメソッドのみを呼び出すことができます。[2]

1. O自体
2. mのパラメーター
3. m内で作成/インスタンス化されたオブジェクト
4. Oの直接コンポーネントオブジェクト
5. Oでアクセス可能な、mのスコープ内のグローバル変数

この法律に従うことの結果の1つは、上記の2番目の例に示すように、長いドットで区切られた文字列で他のメソッドによって返されるオブジェクトのメソッドを呼び出さないようにすることです。

((PowerManager)getSystemService(POWER_SERVICE)).newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"MyWakelockTag").acquire();

これが何をしているのかを理解するのは本当に難しいです。それを理解するには、各プロシージャが何をするのかを理解してから、どの関数がどのオブジェクトで呼び出されているのかを解読する必要があります。最初のコードブロック

PowerManager powerManager=(PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock=powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK,"abc");
wakeLock.acquire();

何をしようとしているのかが明確に示されています-PowerManagerオブジェクトを取得し、PowerManagerからWakeLockオブジェクトを取得してから、wakeLockを取得しています。上記はLoDのルール＃3に従います-これらのオブジェクトをコード内でインスタンス化しているため、これらを使用して必要なことを実行できます。

おそらく別の考え方は、ソフトウェアを作成するとき、簡潔にするためではなく、明確にするために書くべきだということを覚えておくことです。すべてのソフトウェア開発の90％はメンテナンスです。維持するのが苦手なコードを書かないでください。

幸運を祈ります。

注意すべきことは、コードが異なる「深さ」で頻繁に読み取られることです。このコード：

PowerManager powerManager = (PowerManager)getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "abc");
wakeLock.acquire();

「スキム」するのは簡単です。3つのステートメントです。最初にPowerManager。それから私達はWakeLock。その後、我々。これは、各行の先頭を見るだけで簡単にわかります。単純な変数の割り当ては、「Type varName = ...」として部分的に認識し、「...」を単に精神的にざっと読むだけです。同様に、最後の文は明らかに割り当ての形式ではありませんが、2つの名前のみが関係するため、「主な要点」がすぐにわかります。多くの場合、「このコードは何をするのか」と答えようとしているのかどうかを知る必要があるだけです。高いレベルで。acquirewakeLock

ここにあると思われる微妙なバグを追いかけている場合は、明らかにこれをさらに詳しく調べる必要があり、実際には「...」を覚えています。しかし、個別のステートメント構造は、一度に1つのステートメントを実行するのに役立ちます（特に、各ステートメントで呼び出されるものの実装をさらに深く掘り下げる必要がある場合に役立ちます。次のステートメントに進むことができます）。

((PowerManager)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakelockTag")
    .acquire();

これで、すべて1つのステートメントになりました。最上位レベルの構造は、簡単に読むことが簡単ではありません。OPの元のバージョンでは、構造を視覚的に伝えるために改行やインデントを使用しなかったため、括弧をカウントして3つのステップのシーケンスにデコードする必要がありました。マルチパート式の一部がメソッド呼び出しのチェーンとして配置されるのではなく、互いに入れ子になっている場合、これと同様に見える可能性があるため、括弧をカウントせずにそれを信頼することに注意する必要があります。そして、私がインデントを信頼し、このすべての推定されるポイントとして最後の事に目を通すだけなら、それだけで何が.acquire()わかりますか？

しかし、時にはそれがあなたの望むものになります。変換を途中で適用して書いた場合：

WakeLock wakeLock =
     ((PowerManeger)getSystemService(POWER_SERVICE))
    .newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyWakeLockTage");
wakeLock.acquire();

これはWakeLock、「get a then then 」という簡単なスキムと通信しacquireます。最初のバージョンよりもさらにシンプル。取得されるものがであることはすぐに明らかですWakeLock。を取得することPowerManagerがこのコードのポイントにとってかなり重要ではないサブディテールであるwakeLockが、それが重要な場合、実際にPowerManager物を埋めることができるので、すぐに取得しようとしている場合はそれをざっと見るのが自然ですこのコードが何をするかのアイデア。名前を付けないことは、それが一度だけ使用されることを伝え、時にはそれが 重要なこと（スコープの残りが非常に長い場合、それが再び使用されるかどうかを知るためにすべてを読む必要があります。ただし、言語がサポートしている場合、明示的なサブスコープを使用することは別の方法で対処できます）

これは、それがすべてコンテキストとあなたが伝えたいものに依存していることをもたらします。自然言語で散文を書くのと同様に、情報内容の点で基本的に同等である特定のコードを書くための多くの方法が常にあります。自然言語で散文を書く場合と同様に、一般的にどちらを選択するかは、「1回だけ発生するローカル変数を削除する」などの機構的なルールを適用することではありません。むしろ方法コードを書き留めることを選択すると、特定のものが強調され、他のものが強調されなくなります。あなたが実際に強調したいものに基づいて、意識的にそれらの選択をするよう努力する必要があります（技術的な理由で読みにくいコードを書く選択を含む）。特に、（さまざまなレベルで）コードの「要点を把握する」だけの読者に役立つものについて考えてください。これは、式ごとの非常に近い読み取りよりもはるかに頻繁に発生するためです。

これは、Train Wreckという名前のアンチパターンです。交換を回避するいくつかの理由がすでに述べられています。

• 読みにくい
• デバッグが難しい（変数の監視と例外の場所の検出の両方）
• デメテルの法則（LoD）の違反

このメソッドが他のオブジェクトから多くを知っているかどうかを検討してください。メソッドチェーンは、カップリングの削減に役立つ代替手段です。

また、オブジェクトへの参照は本当に安いことを覚えておいてください。

述べられている質問は、「できるならローカル変数を削除すべきか」です。

いいえ、できるからといって排除すべきではありません。

ショップのコーディングガイドラインに従う必要があります。

ほとんどの場合、ローカル変数はコードの読み取りとデバッグを容易にします。

あなたがしたことが好きですPowerManager powerManager。私にとって、このクラスの小文字は、1回限りの使用であることを意味します。

すべきでないのは、変数が高価なリソースを保持する場合です。多くの言語には、クリーンアップ/リリースが必要なローカル変数の構文があります。C＃では使用しています。

using(SQLconnection conn = new SQLconnnection())
{
    using(SQLcommand cmd = SQLconnnection.CreateCommand())
    {
    }
}

1つの重要な側面は、他の回答では言及されていません。変数を追加するたびに、可変状態が導入されます。これは通常、コードをより複雑にし、したがって理解とテストが難しくなるため、悪いことです。もちろん、変数のスコープが小さいほど、問題は小さくなります。

実際に必要なのは、値を変更できる変数ではなく、一時的な定数です。したがって、言語で許可されている場合は、コードでこれを表現することを検討してください。Javaでは使用できfinal、C ++では使用できますconst。ほとんどの機能言語では、これがデフォルトの動作です。

ローカル変数が変更可能な状態の中で最も有害なタイプではないことは事実です。メンバー変数はより多くの問題を引き起こす可能性があり、静的変数はさらに悪化します。それでも、コードでできる限り正確に表現することが重要だと思います。また、後で変更できる変数と、中間結果の単なる名前には大きな違いがあります。そのため、言語でこの違いを表現できる場合は、それを実行してください。