La comprobación de sintaxis o “Compilar” un rubí en los carriles de aplicaciones

Question

Soy nuevo en Rubí y recientemente encontré con un problema en comparación con los valores de la hora de crear una aplicación Ruby on Rails. En un controlador que tenía la siguiente afirmación de que siempre se devuelve falso:

if (user.id != params[:id])

El problema era la user.id (que es un Active Record) es un entero y params [: id] es una cadena. Me tomó un tiempo para resolver esto y al final me lo cambió a:

if (user.id != params[:id].to_i)

Ahora, el comando funciona como se esperaba.

Para evitar este error en el futuro es que hay una manera de "compilar" o conseguir Ruby a emitir una advertencia si intenta comparar 2 tipos diferentes? Algunos otros temas que he encontré con que me gustaría "compilar verificación" son:

• Advertirme si creo una variable, pero no lo uso. Para ayudar a comprobar si hay errores ortográficos en los nombres de variables.
• Asegúrese de que existe un método en una clase para que pueda evitar errores ortográficos nombre del método y también para ayudar a la refactorización, por ejemplo, si cambio el nombre de un método.

Actualmente estoy usando Rubí 1.8.6-27 RC2 con Rails 2.3.2 y RadRails IDE en Windows.

Answer 1

La mejor solución que encontré fue un IDE que hizo la comprobación de sintaxis en la marcha, como RubyMine. No estoy seguro de si habría resuelto mi problema original pero ha ayudado a encontrar y arreglar varios otros sintaxis y errores de compilación. Gracias a todos por sus sugerencias.

Answer 2

Prueba primero, luego el código. Si se escribe pruebas que cubren todas las ramas de su aplicación, se obtiene la garantía de que su código de ambas carreras y produce resultados correctos.

EDIT: Debo señalar que la capacidad de comparar dos tipos, no depende de los nombres de métodos hasta el último segundo, etc., son las características principales de Ruby.

No llama a un método tanto como usted envía un mensaje a un objeto. El objeto es entonces responsable de encontrar la manera de manejar el método. En Rails esto se utiliza para acceder a las columnas de base de datos en ActiveRecord. No hay métodos para las columnas hasta que un mensaje con el nombre de columna se envía al objeto.

tipos estáticos en Ruby va en contra del sistema de tipificación de pato. A menudo se puede obtener el polimorfismo de forma gratuita sin tener que preocuparse por los sistemas de herencia / interfaz compleja.

Sugiero que abarca estas características y compensar la incertidumbre a través de pruebas

Answer 3

Rubí no le permite volver a definir el operador == para el objeto. En Ruby 1.8 no se puede, Ruby 1.9 se supone que debe hacer, pero no he podido conseguir mi guión de trabajo para las clases básicas. Funciona bien para los objetos definidos personalizado.

class Object

  alias :equal_without_warning :==

  def ==(object)
    unless self.class == object.class
      warn("Comparing `#{self.class}' with `#{object.class}'")
    end
    equal_without_warning(object)
  end

end

Suponiendo que no hice algún error de codificación estúpida, la respuesta es NO: no se puede comprobar si se está comparando diferentes tipos de objetos

.

Además, yo diría que no. En realidad, Ruby no está diseñado para trabajar de esta manera, esto es más un enfoque de Java en lugar de estilo Ruby.

Answer 4

No se supone que Ruby a ser seguro. Se le permite comparar dos objetos, y ahí es donde gran parte de su energía proviene de. Raíles no sería posible sin tal diseño dinámico.

A pesar de un lenguaje compilado como Java o C no le impide hacer == en dos objetos. Como dijo Ben, lo mejor es probar primero. Inspeccionar las estructuras de las que está trabajando. Una forma de obtener información sobre un objeto Ruby es utilizar:

puts object.class

Answer 5

En general, la mejor manera (no conozco) para evitar este tipo de problema para los lenguajes dinámicos / script es mover la "lógica" de métodos / comandos y escribir pruebas unitarias para ellos. Básicamente, cualquier cosa que puede fallar debe ser probado. El código de la página debe ser lógica tonto ... en vez de mostrar sólo los elementos que cumplan una serie de criterios, se debe mostrar todos los elementos, y conseguir que la lista de elementos de un método que sólo devuelve los que deben ser mostrados.

Answer 6

Hay dos cosas que me gustaría sugerir:

Uno: Lea sobre IRB (o script / consola para rieles). Una práctica común en el desarrollo de los lenguajes dinámicos es probar fragmentos de código dentro de un intérprete "en vivo" (como el IRB o la consola rieles). Esta práctica se remonta a los primeros lenguajes dinámicos como Smalltalk y Lisp. Ruby-debug también es muy útil para solucionar problemas y habría sido una manera muy fácil de averiguar el error en su ejemplo.

Dos: Lea sobre "Typing pato". "tipos" y variables funcionan un poco diferente en Ruby que muchas personas esperan que lo hagan. Como yo lo entiendo, una variable como user.id no tiene un "tipo". El valor apuntado a por user.id tiene un tipo, pero la propia variable no lo hace. Creo que eso es parte de por qué no hay herramienta que le habría dicho lo que era su error antes de ejecutar el programa. Comparando estas dos variables no es un error ya que las variables no tienen un tipo. user.id estaba apuntando a un entero en ese punto en su programa, pero sería perfectamente legal para asignar user.id para apuntar a una cadena, y en ese momento que la comparación habría hecho mucho más sentido. : -)