Vérification de la syntaxe ou « Compiler » Ruby on Rails d'application

Question

Je suis nouveau à Ruby et a récemment rencontré un problème comparant aux valeurs lors de la création d'une application Ruby on Rails. Dans un contrôleur j'ai eu la déclaration suivante qui a toujours retourné faux:

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

Le problème était le user.id (qui est un enregistrement actif) est un entier et params [: id] est une chaîne. Il m'a fallu un certain temps pour comprendre cela et j'ai finalement changé à:

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

l'énoncé fonctionne comme prévu.

Pour éviter cette erreur à l'avenir est-il un moyen de « compiler » ou obtenir Ruby pour vous avertir si vous essayez de comparer 2 types différents? D'autres questions que je suis tombé sur ce que je voudrais « compiler chèque » sont:

• Me avertir si je crée une variable mais ne l'utilise pas. Pour vous aider à vérifier les fautes de frappe dans les noms de variables.
• Assurez-vous une méthode existe dans une classe pour que je puisse éviter les fautes de frappe nom de la méthode et aussi pour aider refactoring, par exemple, si je renomme une méthode.

Je suis actuellement en utilisant Ruby Rails 1.8.6-27 RC2 avec 2.3.2 et RadRails IDE sur Windows.

Answer 1

La meilleure solution que j'ai trouvé un IDE qui a fait sur la volée vérification de la syntaxe, comme RubyMine. Je ne sais pas si elle aurait résolu mon problème d'origine, mais il m'a aidé à trouver et corriger plusieurs autres syntaxe et des erreurs de compilation. Merci à tous pour vos suggestions.

Answer 2

Tester d'abord, puis le code. Si vous écrivez des tests qui couvrent toutes les branches de votre application, vous obtenez l'assurance que votre code fonctionne et produit les résultats corrects.

EDIT: Je dois souligner que la capacité de comparer deux types, ne pas dépendre des noms de méthodes jusqu'à la dernière seconde, etc. sont des caractéristiques essentielles de Ruby.

Vous n'appelez pas une méthode tant que vous envoyez un message à un objet. L'objet est alors responsable de déterminer comment gérer la méthode. Rails ceci est utilisé pour accéder aux colonnes DB ActiveRecord. Il n'y a aucune méthode pour les colonnes jusqu'à ce qu'un message avec le nom de la colonne est envoyé à l'objet.

Le typage statique Ruby va à l'encontre du système de frappe de canard. On peut souvent obtenir gratuitement polymorphisme sans se soucier des systèmes d'héritage / d'interface complexes.

Je suggère embrasser ces caractéristiques et compenser l'incertitude au moyen de tests

Answer 3

Ruby ne vous permet pas de redéfinir l'opérateur == pour objet. Ruby 1.8 vous ne pouvez pas, Ruby 1.9 était censé faire, mais je n'ai pas été en mesure d'obtenir mon script de travail pour les classes de base. Il fonctionne bien pour les objets définis sur mesure.

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

En supposant que je ne faisais pas une erreur de codage stupide, la réponse est NON: vous ne pouvez pas vérifier si vous comparez différents type d'objets

.

En outre, je vous dis de ne pas. En fait, Ruby est pas conçu pour fonctionner de cette façon, ce qui est plus une approche java plutôt que le style Ruby.

Answer 4

Ruby est pas censé être en sécurité. Il vous permet de comparer deux objets, et c'est là une grande partie de son pouvoir vient. Rails ne serait pas possible sans une telle conception dynamique.

Même un langage compilé comme Java ou C ne vous empêchera pas de faire == sur deux objets. Comme Ben dit, il est préférable de tester d'abord. Inspecter les structures avec lesquelles vous travaillez. Une façon d'obtenir des informations sur un objet Ruby est d'utiliser:

puts object.class

Answer 5

En général, la meilleure façon (que je connaisse) pour éviter ce type de problème pour les langages dynamiques / script est de passer « logique » aux méthodes / commandes et écrire des tests unitaires pour eux. En gros, tout ce qui peut échouer doit être testé. Le code sur la page doit être logique stupide ... au lieu d'afficher uniquement les éléments qui répondent à certains critères, il doit afficher tous les éléments, et d'obtenir cette liste des éléments d'une méthode qui renvoie uniquement ceux qui doivent être affichés.

Answer 6

Deux choses que je vous suggère:

One: lire sur la CISR (ou script / console pour rails). Une pratique de développement commun dans les langages dynamiques est d'essayer des extraits de code à l'intérieur d'un interprète « live » (comme la CISR ou la console de rails). Cette pratique remonte aux premières langages dynamiques comme Smalltalk et Lisp. Ruby-debug est également très utile pour les problèmes de dépannage et aurait été un moyen très facile de comprendre l'erreur dans votre exemple.

Deux: lire sur "Taper Duck". « Types » et les variables fonctionnent un peu différemment dans Ruby que beaucoup de gens les attendent à. Si je comprends bien, une variable comme user.id n'a pas de « type ». La valeur pointée par user.id ne possède un type, mais la variable elle-même ne fonctionne pas. Je crois que cela fait partie des raisons pour lesquelles il n'y a pas d'outil qui vous aurait dit ce que votre erreur était avant l'exécution du programme. En comparant ces deux variables n'est pas une erreur, car les variables ne sont pas un type. user.id pointait un entier à ce moment-là dans votre programme, mais il serait parfaitement légal d'attribuer user.id pour pointer vers une chaîne, à quel point cette comparaison aurait fait beaucoup plus de sens. : -)