/ / ¿Es una buena práctica tener variables locales que comiencen con un guión bajo? - rubí, convenciones de nomenclatura

¿Es una buena práctica tener variables locales que comiencen con guión bajo? - rubí, convenciones de nomenclatura

Estoy entrando en Ruby y vengo del entorno Java y C / C ++.

Mientras codificaba un primer pequeño proyecto en Ruby,de alguna manera se acostumbró a dejar que todas las variables locales comenzaran con un guión bajo. Supongo que mi principal motivación para esto fue una mejor legibilidad y distinción de las llamadas a métodos.

Como en principio solo hay tres tipos de variables ($global, @instance y local), la gran mayoría de las variables comienzan con unguion bajo. No estoy muy seguro de si esto es bueno o malo. Además, en muchos otros idiomas, el guión bajo se sustituye por algún otro carácter.

¿Hay de alguna manera un mejores prácticas sobre la denominación de variables junto a la habitual El caso de Carmel y / o subrayado separado? ¿Cuáles son los hábitos de los "rubistas" profesionales? ¿He pasado por alto algunas convenciones generales de Ruby cuando elegí el subrayado inicial?


editar
Gracias a todas las respuestas y sugerencias. Me ayudó mucho.


Breve resumen de respuestas y comentarios a continuación
(para el visitante con poco tiempo)

Los guiones bajos iniciales van con:

  • argumentos del método: def my_method(_my_arg)
  • bloquear argumentos: p. ej. my_array.each { |_x| puts _x}

Todas las demás variables locales sin guiones bajos iniciales, ya que los programadores que vienen de p. Ej. JavaScript puede confundirse sobre el comportamiento previsto de las variables.

Para una separación visual entre los nombres de las variables y las llamadas a métodos, obligándose a usar "(" soportes ")" con todas las llamadas a métodos pueden aumentar la legibilidad de manera significativa.

Respuestas

1 para la respuesta № 1

No hay nada de malo en tu idea. Pero si tuviera problemas para distinguir las variables locales de las llamadas a métodos, probablemente me obligaría a usar siempre ()"s sobre métodos. (Mi equipo en el trabajo ha discutido hacer de esto parte de nuestros estándares de codificación).

a = thing # var
b = thing() # method

La posible ventaja de esto es la legibilidad para otros. Alguien puede preguntarse por sus principales _ "s, pero usando ()Los "s en todas las llamadas a métodos deben ser claros para todos.


4 para la respuesta № 2

Las respuestas existentes a esta pregunta tienen ahora algunos años y las convenciones han cambiado. Solo debe usar un guión bajo inicial (_some_param), o un guión bajo independiente (_), para indicar que no le importa el valor. rubocop herramienta de pelado de estilo se queja sobre un "inútilasignación "si asigna una variable pero no la usa, pero ignorará las variables con un guión bajo al principio. Esto le permite indicar expresamente que no le importa el valor y que no tiene la intención de utilizarlo.

Aquí hay un caso de uso de ejemplo algo artificial en un contexto RSpec:

describe "login" do
let(:user) { FactoryGirl.create(:user, login: "bob") }
it "must be unique" do
_user1 = user
user2 = User.new login: "bob"
expect(user2.valid?).to be_false
end
end

Aquí estamos indicando que nuestro user El asistente de memorización tiene un efecto secundario y devuelve algo, pero no nos importa. También puedes omitir la tarea por completo, pero ver un simple user en una línea por sí sola parece extraño y no revela la intención con tanta claridad:

describe "login" do
let(:user) { FactoryGirl.create(:user, login: "bob") }
it "must be unique" do
user
user2 = User.new login: "bob"
expect(user2.valid?).to be_false
end
end

Otros escenarios incluyen ignorar los valores en los iteradores o anular un método en el que desea mantener la firma del método original pero no se preocupan por algunos de los valores:

def greet(name, _title)
puts "Hi, #{name}!"
end

3 para la respuesta № 3

En mi experiencia, las variables con prefijo subrayadoen Ruby son muy parecidas a las variables con prefijo de subrayado en JavaScript: un indicador de "no tocar". Más específicamente, se usan cuando el implementador está haciendo algo que realmente no debe entenderse como parte del objeto, o no debería "t debe pensarse como la interfaz conceptual del objeto.

Esto es más claro en el mundo de JavaScript, dondealguien está emulando "privado" prefijando una variable con un guión bajo. Están codificando que hay una parte del objeto que está debajo del capó y se puede ignorar cuando se mira el objeto desde el exterior.

En Ruby, solo he visto esto con cosascomo una caché o una instancia de singleton, el tipo de cosa que debería ser invisible para los consumidores de su objeto. Las variables no subrayadas son cosas que las personas que utilizan su objeto podrían estar interesadas en saber que existen.

En cualquier caso, parecen bastante raros, y los evitaría a menos que quieras enviar una señal al siguiente chico que se acerca de que está sucediendo algo de magia o vudú extra.

En cuanto a hacer una distinción para las llamadas a métodos, si le preocupa que pueda haber confusión entre un método y una variable local, llamaría al método en self para aclarar. Por ejemplo:

def foo
...
end

def some_method
foo # method
bar # variable
end

Si esto no parece claro por alguna razón, puede aclarar con

def some_method
self.foo
bar
end

1 para la respuesta № 4

Viendo como las variables de instancia tienen el @ firmar delante de ellos, y las variables globales tienen el $ firmar delante de ellos ya en ruby, esprobablemente no sea necesario poner un carácter de subrayado delante de los nombres de las variables. Dicho esto, no creo que sea una mala práctica necesariamente. Si te ayuda a leer o escribir tu código en Ruby, entonces deberías usarlo.

A veces he visto código Ruby en el que un argumento para un método de instancia en una clase tiene un guión bajo delante. Tal como:

def my_method(_argument1)
# do something
end

Y creo que cuando se trata de unclase que puede tener sus propios atributos, como un archivo de modelo en rieles, por ejemplo, esto puede ser útil para que sepa que está tratando con una variable que se ha pasado al método en lugar de uno de los atributos que pertenece a la clase / modelo.