2009-03-03 14 views

Respuesta

42

Técnicamente, realmente no importa. require es solo una llamada a método normal, y el alcance al que se llama no afecta la forma en que funciona. La única diferencia que hace la ubicación es que se ejecutará cuando se evalúe el código en el que se coloca.

En términos prácticos, debe ponerlos en la parte superior para que las personas puedan ver las dependencias del archivo de un vistazo. Ese es el lugar tradicional para eso.

+0

¿Eso significa que podrías hacer que una aplicación Ruby sea más "eficiente" (menos memoria, tiempo de ejecución más rápido? Sí, sé que requiere de todos modos, pero ...) ejecutando solo el método requiere llamar * si * realmente lo necesitas ¿eso? – Ash

+0

@Ash: No diría que sea particularmente probable. Es * posible *, pero en la mayoría de los casos, la penalización de ejecución exige que cada vez que se llame a un método supere cualquier ahorro que pueda esperar. Lo he hecho un par de veces, pero solo bajo circunstancias bastante extrañas. – Chuck

+0

@Ash: Además, lo más importante es que daña la legibilidad. Si un archivo es tan costoso de solicitar, probablemente sea un problema en sí mismo. Por lo general, no vale la pena dañar la legibilidad para. – Chuck

19

en la parte superior.

require 'rubygems' 
require 'fastercsv' 

class MyClass 
    # Do stuff with FasterCSV 
end 
3

En la parte superior del archivo, la mayoría (pero no todos) los idiomas manejan las importaciones de esta manera. Me parece mucho más limpio y fácil de manejar de esta manera.

Creo que sólo tiene sentido esta manera realmente ... como las que recibe a mitad de camino en un archivo a continuación:

class Foo 
    def initialize(init_value) 
    @instance_var = init_value 

# some 500 lines of code later.... 

    end 
end 

class Bar 
# oh look i need an import now! 
require 'breakpoint' 

como se puede ver, sería muy difícil realizar un seguimiento de ellos. Sin mencionar que si quería usar las funciones importadas anteriormente en su código, probablemente tendría que retroceder e incluirlo nuevamente porque la otra importación sería específica para esa clase. La importación de los mismos archivos crearía una gran sobrecarga durante el tiempo de ejecución también.

+0

Es posible que no aumente la sobrecarga. No estoy seguro acerca de ruby, pero la importación de otros módulos en python está en caché. –

13

Veo una posible razón para no poner un require en la parte superior del archivo: donde es caro de cargar y no siempre se ejecuta. Un caso que se me ocurre es cuando, por ejemplo, el código y sus pruebas están en el mismo archivo, que es algo que me gusta hacer de vez en cuando para el código de una pequeña biblioteca en particular. Luego puedo ejecutar el archivo desde mi editor y ejecutar las pruebas. En este caso, cuando el archivo es require d desde otro lugar, no deseo que se cargue test/unit.

Algo un poco como esto:

def some_useful_library_function() 
    return 1 
end 

if __FILE__ == $0 
    require 'test/unit' 
    class TestUsefulThing < Test::Unit::TestCase 
    def test_it_returns_1 
     assert_equal 1, some_useful_library_function() 
    end 
    end 
end 
9

Realmente no importa donde se los pone, pero si se los pone dentro una expresión class o module, entonces parece que va a importar lo que sea está en el archivo require d en el espacio de nombres de la clase, lo que no es cierto: todo termina en el espacio de nombre global (o en los espacios de nombre que se definan en la biblioteca).

Por lo tanto, mejor colocarlos en la parte superior para evitar confusiones.

1

Siento que el requiere la declaración pertenece dentro de la clase. El uso de clases significa que estamos aceptando un principio básico de OOP, es decir, los objetos deben estar lo más unidos posible. Para mí eso implica minimizar las dependencias externas. Si más adelante muevo una clase a su propio archivo, no quiero que se rompa porque no localicé todas las declaraciones necesarias que consume la clase.

No causa ningún problema tener duplicados requieren declaraciones en un archivo y simplifica la refactorización que inevitablemente tendrá lugar por el siguiente programador que heredará su código.

Cuestiones relacionadas