¿Es siempre la mejor práctica declarar una variable?

El mantenimiento es el rey. Es la parte más cara del desarrollo de software y cualquier cosa que pueda hacer para hacerlo más fácil es buena.

Las variables son buenas porque al depurar, puede inspeccionar los resultados de las funciones y cálculos.

Absolutamente no. La única vez que crearía una variable para un solo uso como este es si aumenta significativamente la legibilidad de mi código.

En mi opinión, si haces algo como

int a = SomeFunc();
int b = SomeFunc2();
int c = a + b;
SomeFunc3(c);

Es mejor simplemente hacer

int a = SomeFunc();
int b = SomeFunc2();
SomeFunc3(a + b);

O simplemente

SomeFunc3(SomeFunc() + SomeFunc2());

Si no estoy manipulando con la variable después de calcularla, entonces creo que es mejor no declararla porque solo obtienes más líneas de código y mucho más espacio para cometer algún error más tarde cuando tu código se hace más grande

Las variables vienen a servir a los siguientes dos propósitos por encima de todo:

1. Titular de los datos (e información)
2. Potenciador de la legibilidad

Por supuesto, se puede decir más sobre el trabajo de una variable, pero esas otras tareas son menos importantes aquí, y son mucho menos relevantes.

Los dos puntos anteriores tienen la misma importancia en lo que a mí respecta.

Si cree que declarar una variable mejorará la legibilidad, o si cree que los datos almacenado en esa variable será necesario muchas veces (y en cuyo caso, almacenarlo en un nombre bien var aumentará de nuevo la legibilidad), entonces por todos los medios crear una nueva variable.

La única vez que aconsejo estrictamente que no se creen más variables es cuando el desorden de demasiadas variables afecta la legibilidad más que la ayuda, y esto no se puede deshacer mediante la extracción del método.

Sugeriría que el registro con frecuencia hace que la declaración de variables sea digna de mención, y cuando necesita saber qué es algo específico y necesita rastrear ese valor específico. Y tú estás talando, ¿no? La tala es buena. El registro es correcto. La tala es libertad y unicornios y cosas felices.

No siempre uso una variable. Como ejemplo, si tengo un método que evalúa algo y devuelve true / false, normalmente estoy devolviendo la expresión. Los resultados se registran en otro lugar, y tengo las entradas registradas, así que siempre sé lo que pasó.

Depende de la situación. No hay una práctica que sea mejor para todos. Para algo así de simple, puede omitir la creación de una nueva variable, pero lo mejor que puede hacer es retroceder y ver qué tan legible es su expresión y ver si la introducción de una variable intermedia ayudará a la situación.

Hay dos objetivos al tomar esta decisión:

• Legibilidad - el código es legible y código autoexplicativo
• Optimización - el código no tiene cualquier cálculo innecesario

Si nos fijamos en esto como un problema de optimización podría parecer menos subjetivo

Más legible en una escala del 1 al 10 siendo 10 el más fácil. El uso de nombres de variables sensibles puede darle un 2, mostrando el cálculo en línea puede darle un 3 (ya que el usuario no tiene que buscar qué es "dinero", solo está allí en esa línea de código). etc etc. Esta pieza es subjetiva, usted y las empresas para las que trabaja definen lo que es legible y puede construir este modelo de costos a partir de esa experiencia.

La ejecución más óptima no es subjetiva. Si escribes "libras + peniques" donde quieras que vaya el cálculo del dinero, estás perdiendo tiempo de procesador. Si Sé que la adición es un mal ejemplo, pero sigue siendo cierto. Digamos que la ejecución mínima de un proceso es simplificado a la asignación de memoria de variables, asignaciones y cálculos. Tal vez una o dos de estas adiciones en el código estarán bien para la legibilidad, pero en algún momento se convierte en un desperdicio completo en el procesador. Esta es la razón por la que existen variables, asignar un poco de espacio para almacenar el valor, nombrarlo dinero para que el usuario sepa lo que es, y hacer referencia a esa variable "dinero" en todas partes que se necesita.

Esto tiene más sentido a medida que miras los bucles. digamos que desea sumar 1000 valores en el siguiente bucle.

money = factor[1] + factor[2] + ... + factor[n]

Puedes hacer esto donde quieras usar el valor del dinero para que cualquiera que lea tu código sepa en qué consiste el dinero, en su lugar, solo hazlo una vez y escribe algunos comentarios cuando calcules el dinero por primera vez para que cualquier programador pueda volver y hacer referencia a eso.

En resumen, si solo usas dinero una vez y está claro lo que significa el cálculo en línea, entonces, por supuesto, no hagas una variable. Si planea usarlo en todo su código y es el significado se vuelve remotamente confuso, luego declara una variable, guarda el procesador y termina con él. Nota: parcialmente bromeando sobre este enfoque, solo pensé que era divertido responder algo como esto en un formato de modelo de costo:) todavía útil I'de say

Localización y alcance

Para un programador, el conocimiento de las variables locales - su contenido y alcances - es una parte esencial del esfuerzo mental en la comprensión y evolución del código. Cuando reduce el número de variables concurrentes, "libera" al programador para considerar otros factores. Minimizar el alcance es parte de esto. Cada pequeña decisión implica algo sobre su programa.

void f()
{
    int x = ...;  // "we need x (or side effect) in next scope AND
                  // thereafter..."

    {
         int n = ...;  // "n isn't needed at function scope..."
         ...
    } // can "pop" that n mentally...

    ...
}

El ámbito más pequeño es un resultado literal o temporal. Si un valor solo se usa una vez que prefiero usar comentarios en lugar de una variable (tampoco están restringidos a A -a-z0-9_: -)):

x = employees.find("*",                       // name
                   retirement.qualify_at(),   // age
                   num_wives() + num_kids()); // # dependents

Concisión

Mantenerse enfocado en lo que su programa está logrando es importante. Si usted tiene un montón de pantalla real-estate (es decir, líneas de código) conseguir campos en variables, tienes menos código en la pantalla que es realmente responsable de conseguir cosas algorítmicas nivel hecho, y por lo tanto es menos tangible para el programador. Esa es otra razón para mantener el código conciso, entonces:

mantenga útil documentación dirigida y concisa

No recuerdo haber visto nada parecido a is, y creo que está más ligado a diferentes "estilos" de programación. Algunos estilos, como una programación Spartan en realidad intenta declarar lo menos posible. Si no estás tratando de seguir un estilo en particular, entonces es mejor dejar de lado la legibilidad. En tu ejemplo no declararía una variable especial para retenerla. Si estuviera calculando impuestos basados en algún porcentaje del total de esos, entonces podría-o al menos lo haría comenta lo que estaba calculando.