10

私たちは、次のような内部割り当てについて同僚とこの議論をしていました。

return result = myObject.doSomething();

また

if ( null == (point = field.getPoint()) )

これらは受け入れられるものですか、それとも次のものに置き換える必要がありますか?またその理由は?

int result = myObject.doSomething();
return result;

また

Point point = field.getPoint();
if ( null == point)
4

11 に答える 11

20

内部の割り当ては読みにくく、見逃しやすくなっています。複雑な状況では、見逃すことさえあり、エラーを引き起こす可能性があります。

例えば。条件の評価によって変数に値が割り当てられない場合、これは見つけにくいエラーになります。

if (i == 2 && null == (point = field.getPoint())) ...

が false の場合i == 2、ポイント変数は後で値を持ちません。

于 2012-06-27T08:26:18.717 に答える
8

if ( null == (point = field.getPoint()) )

長所：

  • 1 行少ないコード

短所：

  • 読みにくい。
  • pointのスコープをステートメントとそのコード ブロックに制限しません。
  • 私の知る限り、パフォーマンスの改善はありません
  • 常に実行されるとは限りません (その前に false と評価される条件がある場合)。

短所は長所の 4/1 を上回るので、私はそれを避けます。

于 2012-06-27T08:34:25.867 に答える
6

これは主にコードの可読性に関係しています。内部割り当てでは改善が得られないため、コードを読みやすくするために内部割り当てを避けてください。

于 2012-06-27T08:26:37.583 に答える
5

読みやすさのために機能的にNot Necessarily. Definitely Yes

于 2012-06-27T08:27:14.267 に答える
5

それらは避けるべきです。1 行あたりの識別子/操作の数を減らすと、読みやすさが向上し、内部コードの品質が向上します。このトピックに関する興味深い研究があります: http://dl.acm.org/citation.cfm?id=1390647

つまり、結論として、分割します

return result = myObject.doSomething();

の中へ

result = myObject.doSomething();
return result;

他の人があなたのコードを理解し、操作しやすくなります。同時に、コンテキスト内で簡単に理解できる限り、コード ベース全体に散りばめられたいくつかの内部割り当てがあったとしても、それは世界の終わりではありません。

于 2012-06-27T08:37:07.117 に答える
3

どちらの場合も、最初のフォームは読みにくく、デバッガーで値を調べたいときはいつでも変更したくなるでしょう。ステップデバッグ時に「簡潔な」コードを呪った頻度はわかりません。

于 2012-06-27T08:28:14.790 に答える
3

最初のものは厳密には内部割り当てではありませんが、2 番目のケースでは...読みやすさが低下します...しかし、以下のような場合もあります。

while ( null == (point = field.getPoint()) );

このように書くと良いです

于 2012-06-27T08:27:28.317 に答える
3

内部割り当てがプログラムの複雑さを軽減するケースはほとんどif (x != null && y != null && ((c = f(x, y)) > 0) {...}ありません。たとえば、複雑な条件で実行される場合にのみ割り当てが必要です。

しかし、ほとんどの場合、内部代入は可読性を低下させ、簡単に見逃す可能性があります。

内部割り当ては、コンパイラが最適化を行わず、コードを最適化する作業がプログラマーに任されていた 70 年代の C プログラミング言語の最初のバージョンの遺物だと思います。当時は、変数から値を再度読み取る必要がなかったため、内部代入はより高速でしたが、今日では高速なコンピューターと最適化コンパイラーにより、この点はもはや重要ではありません。それでも一部の C プログラマーはそれらに慣れていました。Sun が Java に内部代入を導入したのは、C に似せて、C プログラマーが Java に簡単に変更できるようにしたかったからだと思います。

于 2012-06-27T08:44:57.957 に答える
2

より冗長な形式は、Eclipse などのデバッガーでの追跡も容易にします。中間値がより簡単に見えるように、1 行の割り当てを分割することがよくあります。

OP から直接要求されるわけではありませんが、同様のケースは関数呼び出しです。メソッドの引数は行を節約する可能性がありますが、デバッグが難しいためです。

myFunction(funcA(), funcB());

戻り値の型が表示されず、ステップスルーが難しくなります。また、2 つの値が同じ型の場合、エラーが発生しやすくなります。

于 2012-06-27T08:32:12.493 に答える
2

常に作業し、書き込み可能性ではなくコードの可読性を目指してください。同じことが次のようなものに も当てはまります。おそらく、最初のコード スニペットを読むのに問題を抱えていない多くの開発者がいますが、そのほとんどは 2 番目のスニペットに慣れています。a > b ? x : y;

于 2012-06-27T08:27:48.613 に答える
1

内部割り当てを使用しても害はありません。数行のコードを節約できます (ただし、コンパイルや実行時間、メモリは改善されません)。唯一の欠点は、他の人にとっては面倒に見えるかもしれないということです。

于 2012-06-27T08:27:25.243 に答える