x + = yのようなショートカットが良い習慣と見なされるのはなぜですか？

これらが実際に何と呼ばれているのか分かりませんが、私は常にそれらを見ています。Pythonの実装は次のようなものです。

x += 5の略記法としてx = x + 5。

しかし、なぜこれが良い習慣と見なされるのでしょうか？Python、C、Rなどについて読んだほぼすべての書籍やプログラミングチュートリアルで、この問題に出くわしました。スペースを含む3つのキーストロークを節約できるので便利です。しかし、私がコードを読んでいるとき、彼らはいつも私をつまずかせるように見えます、そして少なくとも私の心には、それをそれ以上ではなく、読みにくくします。

これらが至る所で使用されている明確で明白な理由がありませんか？

速記ではありません。

+=シンボルは、1970年代にC言語で登場し、 - 「スマートアセンブラ」のCアイデアとは明らかに異なるマシン命令とadressingモードに対応しています。

「i=i+1」、「」、"i+=1「」のようなもの++iは、抽象的なレベルでは同じ効果を生み出しますが、低レベルではプロセッサーの異なる動作方法に対応します。

特にこれら3つの式は、i変数がCPUレジスタに保存されているメモリアドレスにあると仮定し（名前を付けましょうD-「intへのポインタ」と考えてください）、プロセッサのALUはパラメータを受け取り、結果を「アキュムレータ」（Aと呼びましょう-intと考えてください）。

これらの制約により（その期間のすべてのマイクロプロセッサで非常に一般的）、翻訳はほとんどの場合

;i = i+1;
MOV A,(D); //Move in A the content of the memory whose address is in D
ADD A, 1;  //The addition of an inlined constant
MOV (D) A; //Move the result back to i (this is the '=' of the expression)

;i+=1;
ADD (D),1; //Add an inlined constant to a memory address stored value

;++i;
INC (D); //Just "tick" a memory located counter

最初の方法は最適ではありませんが、定数（ADD A, BまたはADD A, (D+x)）の代わりに変数を使用して操作する場合、またはより複雑な式を変換する場合（スタック内のプッシュ低優先度操作ですべてが沸騰し、高優先度を呼び出し、ポップする場合）すべての引数が削除されるまで繰り返します）。

2番目は「ステートマシン」のより典型的なものです。「式を評価する」のではなく、「値を操作する」のです。これらの種類の命令は、より複雑な表現が必要な場所では使用i = 3*i + i-2できませんi。

3番目の（さらに単純な）手法では、「加算」という考えさえ考慮されていませんが、カウンターに対してより「プリミティブ」な（計算的な意味での）回路を使用しています。レジスタを後付けしてカウンタにするために必要な組み合わせネットワークは小さく、したがって全加算器のものよりも高速であるため、命令は短絡され、ロードが速く、すぐに実行されます。

コンパイラーの最適化を可能にする最新のコンパイラー（現在はCを参照）では、利便性に基づいて対応関係を入れ替えることができますが、セマンティクスには概念的な違いがあります。

x += 5 手段

• xで識別される場所を見つける
• 5を追加します

しかし、x = x + 5意味：

• x + 5を評価する
  • xで識別される場所を見つける
  • xをアキュムレーターにコピーします
  • アキュムレーターに5を追加します
• 結果をxに保存します
  • xで識別される場所を見つける
  • アキュムレーターをそれにコピーします

もちろん、最適化は

• 「xの検索」に副作用がない場合、2つの「検索」を1回実行できます（xはポインタレジスタに格納されたアドレスになります）
• ADDが&xアキュムレータの代わりに適用される場合、2つのコピーは省略できます。

したがって、最適化されたコードが一致するようにしx += 5ます。

ただし、これは「xを検出」に副作用がない場合にのみ可能です。

*(x()) = *(x()) + 5;

そして

*(x()) += 5;

以来、意味的に異なっているx()（了解が副作用x()の周りに奇妙なことをやって返す関数であるint*）を2回または一回生成されます。

間の等価性x = x + yとは、x += y原因特定の場合には、従ってある+=と=直接L値に適用されます。

Pythonに移行するために、Cから構文を継承しましたが、インタープリター言語での実行の前に翻訳/最適化がないため、物事は必ずしもそれほど密接に関連しているわけではありません（解析ステップが1つ少ないため）。ただし、インタープリターは3種類の式の異なる実行ルーチンを参照でき、式の形成方法と評価コンテキストに応じて異なるマシンコードを利用できます。

詳細が好きな人のために...

すべてのCPUにはALU（算術論理ユニット）があります。ALUは、本質的には、命令のオペコードに応じてレジスタおよび/またはメモリに入力および出力が「プラグイン」される組み合わせネットワークです。

バイナリ演算は通常、「どこかで」入力が行われるアキュムレータレジスタの修飾子として実装されます。どこかは、命令フロー自体の内部（マニフェスト定数：ADD A 5に一般的）-別のレジストリ内（式の計算に一般的）一時的：例：ADD AB）-メモリ内で、レジスタで指定されたアドレスで（例：ADD A（H）をフェッチするデータの例）-この場合、Hは逆参照ポインターのように機能します。

この擬似コードでx += 5は、

ADD (X) 5

しばらくはx = x+5あります

MOVE A (X)
ADD A 5
MOVE (X) A

つまり、x + 5は、後で割り当てられる一時的なものを提供します。x += 5xで直接動作します。

実際の実装は、プロセッサの実際の命令セットに依存します。ADD (.) cオペコードがない場合、最初のコードは2番目になります。

そのようなオペコードがあり、最適化が有効になっている場合、2番目の式は、逆方向の移動を排除してレジスタオペコードを調整した後、最初の式になります。

それについてどう考えるかにもよりますが、実際はわかりやすいので理解しやすいです。例：

x = x + 5 「xを取得し、5を追加し、その新しい値をxに戻す」という精神処理を呼び出します。

x += 5 「xを5増やす」と考えることができます

したがって、それは単なる速記ではなく、実際に機能をより直接的に説明しています。多数のコードを読むと、把握しやすくなります。

少なくともPythonではx += y、x = x + yまったく異なることができます。

たとえば、

a = []
b = a

その後a += [3]になりa == b == [3]ながら、a = a + [3]になりますa == [3]とb == []。つまり+=、オブジェクトをその場で変更します（そうするかもしれませんが、__iadd__メソッドを定義して好きなことをほとんど実行できます）=と同時に、新しいオブジェクトを作成して変数をバインドします。

NumPyで数値処理を行う場合、これは非常に重要です。これは、配列の異なる部分への複数の参照が頻繁に発生するためです。また、他の参照がある配列の一部を誤って変更しないようにすることが重要です。または配列を不必要にコピーします（非常に高価になる可能性があります）。

それはイディオムと呼ばれます。プログラミングイディオムは、特定のプログラミング構成を一貫して記述する方法であるため便利です。

誰かが書いx += yているときは、それが複雑な操作ではなく、x増分されていることを知っていますy（ベストプラクティスとして、通常、私はより複雑な操作とこれらの構文の省略形を混在させません）。これは、1をインクリメントするときに最も意味があります。

@Pubbyのポイントをもう少し明確にするために、 someObj.foo.bar.func(x, y, z).baz += 5

+=オペレーターがいない場合、次の2つの方法があります。

1. someObj.foo.bar.func(x, y, z).baz = someObj.foo.bar.func(x, y, z).baz + 5。これはひどく冗長で長いだけでなく、遅いです。したがって、人はする必要があります
2. 一時変数を使用しますtmp := someObj.foo.bar.func(x, y, z); tmp.baz = tmp.bar + 5。これは問題ありませんが、単純なことには多くのノイズがあります。これは実際には実行時に起こることと非常に似ていますが、書くのは面倒で、使用+=するだけでコンパイラ/インタプリタに作業が移ります。

+=他のそのような演算子の利点は否定できませんが、それらに慣れるのは時間の問題です。

短くて簡単であり、おそらく基礎となるアセンブリ言語に触発されたのは確かですが、ベストプラクティスである理由は、エラーのクラス全体を防止し、コードの確認と確認を容易にすることですそれが何をするか。

と

RidiculouslyComplexName += 1;

関係する変数名は1つだけであるため、ステートメントの動作は確実です。

と RidiculouslyComplexName = RidiculosulyComplexName + 1;

両者がまったく同じであることは常に疑いの余地があります。バグを見ましたか？下付き文字と修飾子が存在すると、さらに悪化します。

+ =表記は慣用的で短くなっていますが、これらが読みやすい理由ではありません。コードを読むことの最も重要な部分は、構文を意味にマッピングすることであり、したがって、構文がプログラマーの思考プロセスに近いほど、読みやすくなります（これは定型コードが悪い理由でもあります：それは思考の一部ではありませんプロセスですが、コードを機能させるために必要です）。この場合、思考は「xに5を加えた値」ではなく、「xに5を加えた値にする」ではありません。

短い表記法は読みやすさに悪い場合があります。たとえば、ifステートメントがより適切な場合に三項演算子を使用する場合です。

これらの演算子が最初に「Cスタイル」言語である理由についての洞察については、34年前のK＆R 1st Edition（1978）からの次の抜粋があります。

簡潔さとは別に、代入演算子には、人々の考え方によりよく対応できるという利点があります。「iに2を加算」または「iに2を加算」と言います。「iを取得して2を追加し、結果をiに戻します」ではありません。したがってi += 2。さらに、次のような複雑な式の場合

yyval[yypv[p3+p4] + yypv[p1+p2]] += 2

割り当て演算子はコードを理解しやすくします。なぜなら、2つの長い式が実際に同じであることを読者が苦労してチェックする必要がないためです。また、代入演算子は、コンパイラがより効率的なコードを生成するのに役立つ場合もあります。

この文章から、ブライアンカーニハンとデニスリッチー（K＆R）は、複合代入演算子がコードの読みやすさを助けたと信じていることは明らかだと思います。

K＆Rがそれを書いてから長い時間が経ち、人々がどのようにコードを書くべきかについての多くの「ベストプラクティス」は、それ以来変化または進化しています。しかし、このprogrammers.stackexchangeの質問は、複合割り当ての読みやすさについて苦情を言っている人を思い出すことができるのは初めてですので、多くのプログラマが問題を見つけているのでしょうか？繰り返しますが、私がこれを入力すると、質問には95の賛成票があります。

可読性に加えて、実際には異なること+=を行います。左のオペランドを2回評価する必要はありません。

たとえば、2回expr = expr + 5評価exprします（expr不純であると仮定）。

他の人が非常によく説明した明らかなメリットに加えて、非常に長い名前を持っている場合は、よりコンパクトです。

  MyVeryVeryVeryVeryVeryLongName += 1;

または

  MyVeryVeryVeryVeryVeryLongName =  MyVeryVeryVeryVeryVeryLongName + 1;

簡潔です。

入力する方がずっと短いです。オペレーターの数が少なくなります。表面積が小さく、混乱の機会が少ない。

より具体的な演算子を使用します。

これは不自然な例であり、実際のコンパイラがこれを実装しているかどうかはわかりません。x + = yは実際には1つの引数と1つの演算子を使用し、xをその場で変更します。x = x + yは、x = zの中間表現を持つことができます。ここで、zはx + yです。後者は、2つの演算子、加算と割り当て、および一時変数を使用します。単一の演算子により、値側がy以外になり得ず、解釈する必要がないことが非常に明確になります。理論的には、プラス演算子と代入演算子よりも高速で実行されるプラス等価演算子を備えた派手なCPUが存在する可能性があります。

それはいいイディオムです。高速であるかどうかは、言語によって異なります。Cでは、右側の変数を増やす命令に変換されるため、高速です。Python、Ruby、C、C ++、Javaなどの最新の言語はすべて、op =構文をサポートしています。コンパクトで、すぐに慣れます。他の人のコード（OPC）でよく見るので、慣れて使用することもできます。他のいくつかの言語で起こることは次のとおりです。

Pythonでは、タイピングx += 5により整数オブジェクト1が作成され（プールから描画される場合もあります）、5を含む整数オブジェクトが孤立します。

Javaでは、暗黙のキャストが発生します。入力してみてください

int x = 4;
x = x + 5.2  // This causes a compiler error
x += 5.2     // This is not an error; an implicit cast is done.

などの演算子+=は、変数をアキュムレータとして使用している場合、つまり積算合計として非常に便利です。

x += 2;
x += 5;
x -= 3;

以下よりも読みやすいです：

x = x + 2;
x = x + 5;
x = x - 3;

最初のケースでは、概念的に、の値を変更していますx。2番目のケースでは、新しい値を計算し、x毎回それを割り当てています。おそらくそれほど単純なコードを書くことはないでしょうが、考え方は同じままです。新しい値を作成するのではなく、既存の値に対して行っていることに焦点を合わせます。

このことを考慮

(some_object[index])->some_other_object[more] += 5

D0本当に書きたい

(some_object[index])->some_other_object[more] = (some_object[index])->some_other_object[more] + 5

他の回答はより一般的なケースを対象としていますが、別の理由があります。一部のプログラミング言語では、オーバーロードされる可能性があります。例えばスカラ。

Small Scalaレッスン：

var j = 5 #Creates a variable
j += 4    #Compiles

val i = 5 #Creates a constant
i += 4    #Doesn’t compile

クラスが+演算子のみを定義している場合、x+=y実際はのショートカットですx=x+y。

+=ただし、クラスがオーバーロードする場合、次のようにはなりません。

var a = ""
a += "This works. a now points to a new String."

val b = ""
b += "This doesn’t compile, as b cannot be reassigned."

val c = StringBuffer() #implements +=
c += "This works, as StringBuffer implements “+=(c: String)”."

さらに、演算子+and +=は2つの別個の演算子です（これらだけでなく、+ a、++ a、a ++、a + ba + = bも異なる演算子です）。演算子のオーバーロードが利用可能な言語では、これは興味深い状況を作り出す可能性があります。前述のように+、追加を実行するために演算子をオーバーロードする場合+=、同様にオーバーロードする必要があることに注意してください。

一度だけ言ってください：ではx = x + 1、「x」を2回言います。

しかし、「a = b + = 1」と書かないでください。そうしないと、10匹の子猫、27匹のネズミ、犬、ハムスターを殺す必要があります。

変数の値を変更しないでください。コードが正しいことを証明しやすくなります。関数型プログラミングを参照してください。しかし、あなたがそうするなら、それは一度だけ言うことはないほうが良いです。