El código auto documentado es más fácil de leer y mantener
Siga el Principio de Menos asombro y el precepto del código como documentación : use una variable para un objetivo, para que su uso sea fácil de entender y el código fácil de leer sin explicaciones.
El código correctamente estructurado es más fácil (por lo tanto, más barato) para (re) usar
Además, aquí parece que querysiempre se usa para preparar una declaración antes de ejecutarla. Probablemente sea una señal de que desea refactorizar parte de este código en uno (o más) métodos auxiliares para preparar y ejecutar la consulta (para cumplir con el principio DRY ).
De esta manera, efectivamente:
- use solo una variable en su método auxiliar para identificar la consulta del contexto actual,
- necesita escribir menos código cada vez que quiera volver a ejecutar una consulta,
- haga que su código sea más legible para otros.
Ejemplos:
Considere esto, tomado de su ejemplo, donde la versión refactorizada es obviamente mejor. Por supuesto, su fragmento fue solo un ejemplo para el propósito de esta pregunta, pero el concepto aún es cierto y escalas.
Tu ejemplo 1:
Strings querycre,queryins,queryup,querydel;
querycre = 'Create table XYZ ...';
execute querycre ;
queryins = 'Insert into XYZ ...';
execute queryins ;
queryup = 'Update XYZ set ...';
execute queryup;
querydel = 'Delete from XYZ ...';
execute querydel ;
Tu ejemplo 2:
Strings query;
query= 'Create table XYZ ...';
execute query ;
query= 'Insert into XYZ ...';
execute query ;
query= 'Update XYZ set ...';
execute query ;
query= 'Delete from XYZ ...';
execute query ;
Ejemplo 3 (pseudocódigo refactorizado):
def executeQuery(query, parameters...)
statement = prepareStatement(query, parameters);
execute statement;
end
// call point:
executeQuery('Create table XYZ ... ');
executeQuery('Insert into XYZ ...');
executeQuery('Update XYZ set ...');
executeQuery('Delete from XYZ ...');
El beneficio se muestra con la reutilización regular.
Anécdota personal
Originalmente comencé como programador en C trabajando con espacio limitado en pantalla, por lo que reutilizar variables tenía sentido tanto para el código compilado (en ese entonces) como para permitir que más código sea legible a la vez.
Sin embargo, después de pasar a los lenguajes de nivel superior y repasar la programación funcional, me acostumbré a usar variables inmutables y referencias inmutables siempre que sea posible para limitar los efectos secundarios.
¿Qué hay para mi ahí dentro?
Si tiene la costumbre de que todas las entradas de su función sean inmutables y devuelva un nuevo resultado (como lo haría una verdadera función matemática), se acostumbra a no duplicar las tiendas.
Por extensión, esto lleva a:
- escribes funciones cortas,
- con objetivos bien definidos,
- que son más fáciles de entender
- reutilizar,
- extender (ya sea por herencia OO o por encadenamiento funcional),
- y documento (como ya autodocumentado).
No estoy diciendo que no haya ningún beneficio para el estado mutable aquí, solo estoy señalando cómo el hábito podría crecer en usted y cómo afecta la legibilidad del código.