2009-11-18 24 views
10

veces uso variables temporales para acortar los identificadores:¿Es una mala práctica usar variables temporales para evitar escribir?

private function doSomething() { 
    $db = $this->currentDatabase; 
    $db->callMethod1(); 
    $db->callMethod2(); 
    $db->callMethod3(); 
    $db->... 
} 

Aunque este es un ejemplo de PHP, que estoy preguntando en general:

¿Es esta mala práctica? ¿Hay algún inconveniente?

+0

Posibles pérdidas de memoria. – Geo

+10

@Geo: ¿Por qué? Como una variable creada localmente, debe vivir solo hasta que la función finalice. ¿Dónde está la fuga de memoria? –

Respuesta

16

Este ejemplo está perfectamente bien, ya que lo está usando en funciones/métodos.

La variable se desconectará justo después de que finalice el método/función, por lo que no hay mucha fuga de memoria o qué.

También al hacer esto, se implementa "algo así como" DRY - no se repita.

¿Por qué escribir tantos $this->currentDatabase cuando puede escribir $db. ¿Y qué pasa si tiene que cambiar $this->currentDatabase por algunos otros valores?

+0

Tendrá una pérdida de memoria si almacena esa referencia en alguna parte y se olvida de ella. – Geo

+6

@Geo: si está almacenando la referencia en alguna parte, lo hubiera estado haciendo * de todos modos *. Esta pregunta es claramente acerca de las variables locales como alias de un tipo. Si "accidentalmente" almacena variables locales globalmente, de todos modos se encontrará con grandes problemas. –

+0

Aún así, la variable también se desactivará justo después de que finalice la ejecución del script. – mauris

7

En realidad, usted no está tratando de evitar escribir (de lo contrario, tendrá que utilizar un mecanismo de terminación en su editor), pero simplemente está haciendo su función más legible (mediante el uso de "abreviaturas") Lo que es algo bueno.

Los inconvenientes se mostrará cuando se empieza a hacer esto para evitar tener que escribir (y legibilidad sacrificio)

3

En general:

  • Tanto $ db como $ this-> currentDatabase punto a exactamente el mismo objeto.
  • El pequeño espacio asignado a $ db es liberado (o elligeable para la recolección de basura) cuando la función termina

así que diría: no, no es una mala práctica.

1

Si hace esto con cuidado, está absolutamente bien. Siempre que solo use unas pocas de estas variables en una pequeña cantidad de código y dentro de pequeñas funciones, creo que esto está bien.

Si tiene muchas de estas variables y están mal nombradas como i, j, l y f en la misma función, la comprensibilidad de su código sufrirá. Si este es el caso, prefiero escribir un poco más y no tener un código comprensible. Esta es una de las razones por las que un buen IDE tiene la finalización automática del código.

1

No, creo que esto está bien. A menudo, el rendimiento, si no es tan crítico como el código limpio legible.

Además, está intercambiando memoria un pequeño golpe de asignación en la pila para llamadas de método más rápidas, evitando desreferencia adicional.

3

Parece que recuerdo que Steve McConnell recomienda no usar variables temporales en "Code Complete". A riesgo de cometer herejía, tengo que estar en desacuerdo. Prefiero la legibilidad adicional introducida. También me encuentro añadiéndolos para ayudar en la depuración de un solo paso, y luego no veo ninguna razón para eliminarlos.

+0

Estoy de acuerdo con usted y no estoy de acuerdo con McConnell aquí. También prefiero usar variables locales sobre llamadas de método de línea múltiple, por ejemplo. También facilita la depuración, porque puede verificar el valor de cada variable. – panschk

3

Depende del contrato en $ this-> currentDatabase. ¿Puede cambiar en cualquier momento, después de cualquier llamada al método?Si cambia, ¿se supone que debes seguir utilizando el objeto que hiciste cuando hiciste tu primera llamada a la base de datos, o se supone que siempre debes usar el valor actual? Esto dicta que si debe siempre use $ this-> currentDatabase, o si debe siempre guárdelo en una variable antes de usar.

Por lo tanto, en rigor, esto no es una cuestión de estilo en absoluto.

Pero, asumiendo que el miembro nunca se cambia durante las llamadas a funciones como esta, no hace ninguna diferencia. Diría que almacenarlo en una variable es un poco mejor, ya que es más fácil de leer y evita el acceso de un miembro a un objeto en cada operación. El compilador puede optimizarlo si es bueno, pero en muchos idiomas dichas optimizaciones son muy difíciles, y acceder a una variable local es casi invariablemente más rápido que acceder a un miembro de un objeto.

1

No creo que haya una penalización de rendimiento si usa la variable original en lugar de saltearse la primera desreferencia ($this->currentDatabase).

Sin embargo, como la legibilidad se mejora mucho con la abreviatura, ¡adelante!

Por supuesto, también dependerá de las convenciones de codificación de su equipo.

+0

Si obtener $ this-> CurrentDatabase implica una llamada de función (no conozco ningún PHP, así que no puedo decirlo), debería ser MÁS RÁPIDO usar una variable temporal, ya que la función solo se llama una vez. Nut tenga en cuenta la respuesta de Nakedible. –

Cuestiones relacionadas