¿Por qué los atajos como x + = y se consideran una buena práctica?

No tengo idea de cómo se llaman en realidad, pero los veo todo el tiempo. La implementación de Python es algo así como:

x += 5como una notación abreviada para x = x + 5.

Pero, ¿por qué se considera esto una buena práctica? Lo he encontrado en casi todos los libros o tutoriales de programación que he leído para Python, C, R , etc. Entiendo que es conveniente, ahorrando tres pulsaciones de teclas, incluidos los espacios. Pero siempre parecen hacerme tropezar cuando leo el código y, al menos en mi opinión, lo hacen menos legible, no más.

¿Me estoy perdiendo alguna razón clara y obvia por la que se usan en todo el lugar?

No es taquigrafía.

El +=símbolo apareció en el lenguaje C en la década de 1970 y, con la idea C de "ensamblador inteligente", corresponde a una instrucción de máquina y un modo de dirección claramente diferentes:

Cosas como " i=i+1", "i+=1"y" ++i", aunque en un nivel abstracto producen el mismo efecto, corresponden en un nivel bajo a una forma diferente de trabajar del procesador.

En particular, esas tres expresiones, suponiendo que la ivariable reside en la dirección de memoria almacenada en un registro de la CPU ( Dpor ejemplo, piense en ello como un "puntero a int") y la ALU del procesador toma un parámetro y devuelve un resultado en un "acumulador" (llamémoslo A - piense en ello como int).

Con estas restricciones (muy comunes en todos los microprocesadores de ese período), la traducción probablemente será

;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

La primera forma de hacerlo es desóptima, pero es más general cuando se opera con variables en lugar de constantes ( ADD A, Bo ADD A, (D+x)) o cuando se traducen expresiones más complejas (todas se reducen al presionar la operación de baja prioridad en una pila, llame a la alta prioridad, pop y repita hasta que todos los argumentos hayan sido eliminados).

El segundo es más típico de la "máquina de estado": ya no estamos "evaluando una expresión", sino "operando un valor": todavía usamos la ALU, pero evitamos mover los valores como resultado permitido reemplazar el parámetro. Este tipo de instrucción no se puede usar donde se requieren expresiones más complicadas: i = 3*i + i-2no se puede operar en su lugar, ya que ise requiere más veces.

El tercero, incluso más simple, ni siquiera considera la idea de "suma", sino que usa un circuito más "primitivo" (en sentido computacional) para un contador. La instrucción se acorta, se carga más rápido y se ejecuta de inmediato, ya que la red combinatoria requerida para actualizar un registro para convertirlo en un contador es más pequeña y, por lo tanto, más rápida que la de un sumador completo.

Con los compiladores contemporáneos (consulte C, por ahora), que permiten la optimización del compilador, la correspondencia puede intercambiarse según la conveniencia, pero todavía hay una diferencia conceptual en la semántica.

x += 5 medio

• Encuentra el lugar identificado por x
• Añade 5

Pero x = x + 5significa:

• Evaluar x + 5
  • Encuentra el lugar identificado por x
  • Copiar x en un acumulador
  • Añade 5 al acumulador
• Almacenar el resultado en x
  • Encuentra el lugar identificado por x
  • Copia el acumulador

Por supuesto, la optimización puede

• si "encontrar x" no tiene efectos secundarios, los dos "encontrar" se pueden hacer una vez (y x se convierte en una dirección almacenada en un registro de puntero)
• las dos copias se pueden elidir si se aplica ADD &xal acumulador

haciendo que el código optimizado coincida con el x += 5uno.

Pero esto solo se puede hacer si "encontrar x" no tiene efectos secundarios, de lo contrario

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

y

*(x()) += 5;

son semánticamente diferentes, ya que x()los efectos secundarios (admitir x()es una función que hace cosas raras y devolver un int*) se producirán dos o una vez.

La equivalencia entre x = x + yy, por x += ylo tanto, se debe al caso particular donde +=y =se aplican a un valor l directo.

Para pasar a Python, heredó la sintaxis de C, pero como no hay traducción / optimización ANTES de la ejecución en lenguajes interpretados, las cosas no están necesariamente tan íntimamente relacionadas (ya que hay un paso de análisis menos). Sin embargo, un intérprete puede referirse a diferentes rutinas de ejecución para los tres tipos de expresión, aprovechando diferentes códigos de máquina dependiendo de cómo se forme la expresión y del contexto de evaluación.

Para quien le gusta más detalle ...

Cada CPU tiene una ALU (unidad aritmética-lógica) que es, en esencia, una red combinatoria cuyas entradas y salidas están "conectadas" a los registros y / o memoria dependiendo del código de operación de la instrucción.

Las operaciones binarias generalmente se implementan como "modificador de un registro de acumulador con una entrada tomada" en algún lugar ", donde en algún lugar puede estar, dentro del flujo de instrucciones en sí mismo (típico para el contenido manifiesto: ADD A 5), dentro de otro registro (típico para el cálculo de expresiones con temporales: por ejemplo, ADD AB): dentro de la memoria, en una dirección dada por un registro (típico de la obtención de datos, por ejemplo: ADD A (H)) - H, en este caso, funciona como un puntero de referencia.

Con este pseudocódigo, x += 5es

ADD (X) 5

mientras x = x+5es

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

Es decir, x + 5 da un temporal que luego se asigna. x += 5opera directamente en x.

La implementación real depende del conjunto de instrucciones reales del procesador: si no hay ADD (.) ccódigo de operación, el primer código se convierte en el segundo: de ninguna manera.

Si existe dicho código de operación, y la optimización está habilitada, la segunda expresión, después de eliminar los movimientos inversos y ajustar el código de operación de los registros, se convierte en la primera.

Dependiendo de cómo lo piense, en realidad es más fácil de entender porque es más sencillo. Tomar como ejemplo:

x = x + 5 invoca el procesamiento mental de "tomar x, agregarle cinco y luego asignar ese nuevo valor a x"

x += 5 puede considerarse como "aumentar x en 5"

Entonces, no es solo una taquigrafía, sino que describe la funcionalidad mucho más directamente. Cuando se leen fragmentos de código, es mucho más fácil de entender.

Al menos en Python , x += yy x = x + ypuede hacer cosas completamente diferentes.

Por ejemplo, si lo hacemos

a = []
b = a

entonces a += [3]dará como resultado a == b == [3], mientras que a = a + [3]dará como resultado a == [3]y b == []. Es decir, +=modifica el objeto en el lugar (bueno, podría hacerlo, puede definir el __iadd__método para hacer casi todo lo que quiera), mientras =crea un nuevo objeto y le vincula la variable.

Esto es muy importante cuando se realiza un trabajo numérico con NumPy , ya que con frecuencia termina con múltiples referencias a diferentes partes de una matriz, y es importante asegurarse de no modificar accidentalmente parte de una matriz a la que hay otras referencias, o copiar matrices innecesariamente (lo que puede ser muy costoso).

Se llama modismo . Los modismos de programación son útiles porque son una forma consistente de escribir una construcción de programación particular.

Cada vez que alguien escribe x += y, sabe que xse está incrementando yy no por una operación más compleja (como práctica recomendada, por lo general, no mezclaría operaciones más complicadas y estas sintaxis shorthands). Esto tiene más sentido cuando se incrementa en 1.

Para poner el punto de @ Pubby un poco más claro, considere someObj.foo.bar.func(x, y, z).baz += 5

Sin el +=operador, hay dos formas de hacerlo:

1. someObj.foo.bar.func(x, y, z).baz = someObj.foo.bar.func(x, y, z).baz + 5. Esto no solo es terriblemente redundante y largo, sino que también es más lento. Por lo tanto, uno tendría que
2. Utilizar una variable temporal: tmp := someObj.foo.bar.func(x, y, z); tmp.baz = tmp.bar + 5. Esto está bien, pero es mucho ruido por algo simple. En realidad, esto está muy cerca de lo que sucede en tiempo de ejecución, pero es tedioso escribir y solo usarlo +=cambiará el trabajo al compilador / intérprete.

La ventaja de +=otros operadores similares es innegable, mientras que acostumbrarse a ellos es solo cuestión de tiempo.

Es cierto que es más corto y fácil, y es cierto que probablemente se inspiró en el lenguaje ensamblador subyacente, pero la mejor práctica es que evita toda una clase de errores y facilita la revisión del código y la seguridad Que hace.

Con

RidiculouslyComplexName += 1;

Como solo hay un nombre de variable involucrado, está seguro de lo que hace la declaración.

Con RidiculouslyComplexName = RidiculosulyComplexName + 1;

Siempre hay dudas de que las dos partes son exactamente iguales. ¿Viste el error? Se pone aún peor cuando hay subíndices y calificadores presentes.

Si bien la notación + = es idiomática y más corta, estas no son las razones por las que es más fácil de leer. La parte más importante de la lectura del código es asignar la sintaxis al significado, por lo que cuanto más se aproxime la sintaxis a los procesos de pensamiento del programador, más legible será (esta es también la razón por la cual el código repetitivo es malo: no es parte del pensamiento proceso, pero aún es necesario para que el código funcione). En este caso, el pensamiento es "incrementar la variable x en 5", no "dejar que x sea el valor de x más 5".

Hay otros casos en los que una notación más corta es mala para la legibilidad, por ejemplo, cuando usa un operador ternario donde una ifdeclaración sería más apropiada.

Para tener una idea de por qué estos operadores están en los lenguajes 'C-style', hay un extracto de K&R 1st Edition (1978), hace 34 años:

Aparte de la concisión, los operadores de asignación tienen la ventaja de que se corresponden mejor con la forma en que las personas piensan. Decimos "agregue 2 a i" o "incremente i en 2", no "tome i, agregue 2, luego coloque el resultado nuevamente en i". Por lo tanto i += 2. Además, para una expresión complicada como

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

el operador de asignación hace que el código sea más fácil de entender, ya que el lector no tiene que verificar minuciosamente que dos expresiones largas son realmente iguales, o preguntarse por qué no lo son. Y un operador de asignación puede incluso ayudar al compilador a producir código más eficiente.

Creo que está claro en este pasaje que Brian Kernighan y Dennis Ritchie (K&R) creían que los operadores de asignación compuesta ayudaron con la legibilidad del código.

Ha pasado mucho tiempo desde que K&R escribió eso, y muchas de las 'mejores prácticas' sobre cómo las personas deberían escribir código han cambiado o evolucionado desde entonces. Pero esta pregunta de programmers.stackexchange es la primera vez que recuerdo que alguien expresó una queja sobre la legibilidad de las tareas compuestas, por lo que me pregunto si muchos programadores consideran que son un problema. Por otra parte, mientras escribo esto, la pregunta tiene 95 votos a favor, por lo que tal vez las personas los encuentren discordantes al leer el código.

Además de la legibilidad, en realidad hacen cosas diferentes: +=no tiene que evaluar su operando izquierdo dos veces.

Por ejemplo, expr = expr + 5se evaluaría exprdos veces (suponiendo que exprsea ​​impuro).

Además de los méritos obvios que otras personas describieron muy bien, cuando tienes nombres muy largos es más compacto.

  MyVeryVeryVeryVeryVeryLongName += 1;

o

  MyVeryVeryVeryVeryVeryLongName =  MyVeryVeryVeryVeryVeryLongName + 1;

Es conciso.

Es mucho más corto de escribir. Implica menos operadores. Tiene menos superficie y menos posibilidades de confusión.

Utiliza un operador más específico.

Este es un ejemplo artificial, y no estoy seguro de si los compiladores reales implementan esto. x + = y en realidad usa un argumento y un operador y modifica x en su lugar. x = x + y podría tener una representación intermedia de x = z donde z es x + y. Este último utiliza dos operadores, suma y asignación, y una variable temporal. El operador único deja muy claro que el lado del valor no puede ser otra cosa que y y no necesita ser interpretado. Y, en teoría, podría haber alguna CPU elegante que tenga un operador más-igual que funcione más rápido que un operador más y un operador de asignación en serie.

Es un buen modismo. Si es más rápido o no depende del idioma. En C, es más rápido porque se traduce en una instrucción para aumentar la variable en el lado derecho. Los lenguajes modernos, incluidos Python, Ruby, C, C ++ y Java, admiten la sintaxis op =. Es compacto y te acostumbras rápidamente. Como lo verá mucho en el código de otras personas (OPC), también puede acostumbrarse y usarlo. Esto es lo que sucede en otros idiomas.

En Python, escribir x += 5aún causa la creación del objeto entero 1 (aunque puede extraerse de un grupo) y la huérfana del objeto entero que contiene 5.

En Java, hace que se produzca un lanzamiento tácito. Intenta escribir

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.

Los operadores como +=son muy útiles cuando está utilizando una variable como acumulador , es decir, un total acumulado :

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

Es mucho más fácil de leer que:

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

En el primer caso, conceptualmente, estás modificando el valor en x. En el segundo caso, está calculando un nuevo valor y asignándolo a xcada vez. Y aunque probablemente nunca escribiría código que sea tan simple, la idea sigue siendo la misma ... el foco está en lo que está haciendo a un valor existente en lugar de crear un valor nuevo.

Considera esto

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

D0 realmente quieres escribir

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

Las otras respuestas se dirigen a los casos más comunes, pero hay otra razón: en algunos lenguajes de programación, se puede sobrecargar; por ejemplo, Scala .

Lección de Scala pequeña:

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

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

Si una clase solo define el +operador, de x+=yhecho es un atajo de x=x+y.

Si una clase se sobrecarga +=, sin embargo, no son:

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)”."

Además, los operadores +y +=son dos operadores separados (y no solo estos: + a, ++ a, a ++, a + ba + = b también son operadores diferentes); en idiomas donde la sobrecarga del operador está disponible, esto podría crear situaciones interesantes. Tal como se describió anteriormente: si sobrecarga al +operador para realizar la adición, tenga en cuenta que +=también tendrá que sobrecargarse.

Dilo una vez y solo una vez: en x = x + 1, digo 'x' dos veces.

Pero nunca escriba 'a = b + = 1' o tendremos que matar 10 gatitos, 27 ratones, un perro y un hámster.

Nunca debe cambiar el valor de una variable, ya que facilita probar que el código es correcto; consulte la programación funcional. Sin embargo, si lo hace, entonces es mejor no decir las cosas solo una vez.