¿Debo reutilizar las variables?

Su problema aparece solo cuando sus métodos son largos y están realizando múltiples tareas en una secuencia. Esto hace que el código sea más difícil de entender (y por lo tanto mantener) per se. Reusar las variables agrega un elemento adicional de riesgo, lo que hace que el código sea aún más difícil de seguir y más propenso a errores.

La mejor práctica de la OMI es utilizar métodos suficientemente cortos que solo hagan una cosa, eliminando todo el problema.

La reutilización de variables en un método es una señal fuerte de que debe refactorizarlo / dividirlo.

Entonces, mi respuesta sería que no deberías reutilizarlos, porque si lo haces sería mucho más difícil refactorizarlo más tarde.

Depende.

Algunas variables pueden crearse exactamente con el fin de mantener un cierto tipo de datos, que pueden cambiar durante la ejecución de una función. Los códigos de retorno vienen a la mente aquí, por ejemplo:

void my_function() {
    HRESULT errorcode;
    errorcode = ::SomeWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
    errorcode = ::AnotherWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
}

El nombre de la variable deja muy claro lo que esta variable pretende almacenar. Creo que otros casos de uso como este son posibles, donde una variable es conceptualmente un contenedor que es usado lógicamente por diferentes instancias de cosas muy similares durante el curso de una función.

Sin embargo, en general, esto debe hacerse solo en circunstancias en que sea absolutamente claro para los posibles lectores del código. En ningún caso, excepto tal vez una optimización extrema sin tener en cuenta la legibilidad del código, debe reutilizarse una variable simplemente porque el tipo se ajusta.

Todo esto básicamente se deriva de las buenas prácticas en la denominación de variables. Los nombres deben hablar por sí mismos. Si es difícil poner el propósito exacto para todas las reutilizaciones en un nombre corto, es mejor usar solo variables distintas.

La razón principal por la que no reutilizo las variables (especialmente en las pruebas unitarias) es porque introduce una ruta de código innecesaria, una que es difícil de probar y depurar. Una buena prueba de unidad debe ser independiente de otras pruebas y cuando reutiliza la variable de nivel de clase (instancia) en un dispositivo de prueba de unidad, debe asegurarse de afirmar su estado antes de cada prueba. Una buena prueba unitaria también aísla los defectos, por lo que en teoría cada caso de prueba (método) solo debe afirmar 1 comportamiento para el sistema en prueba. Si sus métodos de prueba están escritos de esta manera, rara vez hay una necesidad o beneficio de reutilizar una variable de nivel de método. Por último, en los idiomas que admiten cierres y procesamiento asíncrono, es muy difícil razonar qué diablos está sucediendo si está reutilizando variables a través de un método.

Debes usar diferentes variables. Si le preocupa que su colega se confunda, deles nombres que cubran claramente sus roles.
Reutilizar variables es una fuente probable de confusión en el futuro; mejor aclararlo ahora.
En algunos casos, se puede reutilizar el mismo nombre de variable; por ejemplo, i en un bucle de conteo simple. En estos casos, debe asegurarse, por supuesto, de que las variables estén dentro de su propio ámbito.

EDITAR: reutilizar variables es a veces una señal de que se ha violado el Principio de responsabilidad única . Compruebe si la variable reutilizada se usa en el mismo rol. Si es así, es posible que no se pueda reutilizar (aunque puede ser preferible tener dos variables diferentes, para restringir el alcance de dichas variables). Si se usa en diferentes roles, tienes una violación de SRP en tus manos.

Hay una situación en la que es posible que desees reutilizar una variable, independientemente del gran consejo dado por otras respuestas: cuando tu compilador necesita ayuda.

En algunos casos, es posible que su compilador no sea lo suficientemente inteligente como para darse cuenta de que la siguiente parte del código ya no está utilizando una determinada variable asignada por el registro. Por lo tanto, no se reutilizará ese registro teóricamente libre para las siguientes variables, y el código generado puede ser sub-óptimo.

Tenga en cuenta que no conozco ningún compilador convencional actual que no logre detectar esta situación correctamente, así que nunca, nunca, haga esto a menos que sepa a ciencia cierta que su compilador está generando código subóptimo. Si está compilando sistemas embebidos especiales con compiladores personalizados, es posible que aún tenga este problema.

Yo diría que NO.

Piense en este escenario: su programa se bloqueó y usted necesita resolver qué sucedió al inspeccionar un volcado de datos ... ¿puede ver la diferencia? ;-)

No, no está mejorando el código que la máquina está ejecutando (... el código de ensamblaje). Deje la reutilización de la memoria que el compilador utiliza para la variable al compilador. Muy a menudo será un registro y la reutilización no le compró nada. Enfócate en hacer que el código sea más fácil de leer.

Depende. En un lenguaje dinámico, donde el tipo reside en valores en lugar de variables, entonces, si tuviera un argumento bien nombrado para una función que, por ejemplo, era una cadena. Si un cambio en el algoritmo significaba que siempre se usaba después de interpretarse como un entero, entonces, como primer borrador, podría hacer el equivalente a

scrote = int (scrote)

Pero eventualmente buscaría cambiar el tipo enviado a la función y observar el cambio en el tipo de parámetro.

Primero, observa tu entorno de desarrollo. Si tiene problemas para depurar porque tiene cinco variables en diferentes ámbitos con nombres idénticos, y el depurador no le muestra cuál de estas variables es la que necesita, entonces no use cinco variables con el mismo nombre. Hay dos formas de lograrlo: use una variable o use cinco nombres diferentes.

Su depurador también puede hacer que sea difícil depurar una función con muchas variables. Si una función con 20 variables es más difícil de depurar que una con 16 variables, entonces podría considerar reemplazar 5 variables por una. ("Debería considerar" no es lo mismo que "siempre debería").

Está bien que una variable se use en varios lugares siempre que la variable siempre tenga el mismo propósito. Por ejemplo, si diez llamadas de función devuelven un código de error, que se maneja inmediatamente para cada llamada, use una variable y no 10. Pero no use la misma variable para cosas completamente diferentes. Como usar "nombre" para un nombre de cliente, y 10 líneas más tarde usando la misma variable para un nombre de empresa, eso es malo y te meterá en problemas. Peor aún, usando "customerName" para un nombre de cliente, y 10 líneas más tarde usando la misma variable "customerName" para un nombre de compañía.

Es importante destacar que nada es una regla de hierro. Todo tiene ventajas y desventajas. Si las "mejores prácticas" sugieren una cosa, y tiene razones para decir que es una mala idea en su situación específica, no lo haga.

Primero, observa tu entorno de desarrollo. Si tiene problemas para depurar porque tiene cinco variables en diferentes ámbitos con nombres idénticos, y el depurador no le muestra cuál de estas variables es la que necesita, entonces no use cinco variables con el mismo nombre. Hay dos formas de lograrlo: use una variable o use cinco nombres diferentes.

Su depurador también puede hacer que sea difícil depurar una función con muchas variables. Si una función con 20 variables es más difícil de depurar que una con 16 variables, entonces podría considerar reemplazar 5 variables por una. ("Debería considerar" no es lo mismo que "siempre debería").

Está bien que una variable se use en varios lugares siempre que la variable siempre tenga el mismo propósito. Por ejemplo, si diez llamadas de función devuelven un código de error, que se maneja inmediatamente para cada llamada, use una variable y no 10. Hay un problema con esto: por lo general, el compilador le avisará cuando use una variable sin inicializar. Pero aquí, si lees el código de error después de la llamada 6, pero la variable no se ha cambiado realmente después de la llamada 5, obtendrás datos inútiles sin que el compilador te advierta. Debido a que la variable se ha inicializado, con datos que ahora son inútiles.

Es importante destacar que nada es una regla de hierro. Todo tiene ventajas y desventajas. Si las "mejores prácticas" sugieren una cosa, y tiene razones para decir que es una mala idea en su situación específica, no lo haga.

Use variables globales cuando necesite mantener un estado o almacenar constantes. Al reutilizar las variables, solo reutiliza el nombre que apunta a una ubicación en la memoria. Los nombres descriptivos en las inicializaciones solo pueden ganarle claridad (asumiendo Java y no un OCD primitivo).

A menos que estés en ofuscación de código a mano o irritando a otros desarrolladores.