Il controllo della sintassi o “Compilazione” Ruby on Rails Application

Question

Sono nuovo di Ruby e di recente sono imbattuto in un problema confrontando i valori durante la creazione di un'applicazione Ruby on Rails. In un controller ho avuto la seguente dichiarazione che ha sempre restituito false:

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

Il problema era l'user.id (che è un Active Record) è un numero intero e params [: id] è una stringa. Mi c'è voluto un po 'per capire questo e alla fine ho cambiato in:

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

Ora l'istruzione funziona come previsto.

Per evitare questo errore in futuro c'è un modo per "compilazione" o ottenere Ruby per avvisare l'utente se si tenta di confrontare 2 tipi differenti? Alcuni altri problemi che ho funzionato in che vorrei "compilazione di controllo" sono:

• Avvisami se creo una variabile, ma non lo uso. Per aiutare a verificare la presenza di errori di battitura nei nomi di variabili.
• Assicurati che il metodo esiste in una classe in modo da poter evitare di nome metodo errori di battitura e anche per aiutare il refactoring, per esempio se si rinomina un metodo.

Attualmente sto usando rubino 1.8.6-27 RC2 con Rails 2.3.2 e RadRails IDE di Windows.

Answer 1

La soluzione migliore che ho trovato è stato un IDE che ha fatto il controllo della sintassi on-the-fly, come ad esempio RubyMine. Non sono sicuro se avrebbe risolto il mio problema originale, ma mi ha aiutato a trovare e risolvere molti altri sintassi e errori di compilazione. Grazie a tutti per i vostri suggerimenti.

Answer 2

Prova prima, poi il codice. Se si scrivono dei test che coprono tutti i settori della vostra applicazione, si ottiene la garanzia che il codice sia corre e produce risultati corretti.

EDIT: Vorrei sottolineare che la capacità di confrontare due tipi, non dipende nomi dei metodi fino all'ultimo secondo, ecc sono caratteristiche fondamentali di rubino.

Non si chiama un metodo così tanto come si invia un messaggio a un oggetto. L'oggetto è quindi responsabile per capire come gestire il metodo. In Rails questo viene utilizzato per accedere alle colonne DB in ActiveRecord. Non ci sono metodi per le colonne fino a quando un messaggio con il nome della colonna viene inviato l'oggetto.

tipizzazione statica in Ruby va contro il sistema duck typing. Spesso Si può ottenere il polimorfismo gratis senza preoccuparsi di schemi di eredità / un'interfaccia complessa.

Suggerisco di abbracciare queste caratteristiche e compensare l'incertezza attraverso test

Answer 3

Rubino non consente di ridefinire l'operatore == per oggetto. In Ruby 1.8 non è possibile, Ruby 1.9 avrebbe dovuto fare, ma non sono stato in grado di ottenere il mio script di lavoro per le classi di base. Funziona bene per oggetti definiti personalizzato.

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

Supponendo che non ho fatto qualche errore di codifica stupido, la risposta è NO: non si può verificare se si sta confrontando diversi tipi di oggetti

.

Inoltre, direi che non. In realtà Rubino non è progettato per funzionare in questo modo, questo è più di un approccio Java piuttosto che sullo stile Ruby.

Answer 4

Rubino non dovrebbe essere al sicuro. Esso consente di confrontare due oggetti, ed è lì che gran parte del suo potere viene da. Rails non sarebbe possibile senza tale design dinamico.

Anche un linguaggio compilato come Java o C non si fermerà dal fare == su due oggetti. Come ha detto Ben, è meglio provare prima. Ispezionare le strutture si sta lavorando con. Un modo per ottenere informazioni su un oggetto Ruby è da utilizzare:

puts object.class

Answer 5

In generale, il modo migliore (che conosco) per evitare questo tipo di problema per i linguaggi dinamici / scripting è quello di spostare "logica" per metodi / comandi e scrivere unit test per loro. In pratica, tutto ciò che può non dovrebbe essere testato. Il codice nella pagina dovrebbe essere la logica muto ... invece di visualizzare solo gli elementi che soddisfano determinati criteri, dovrebbe visualizzare tutti gli elementi, e ottenere quella lista di elementi da un metodo che restituisce solo quelli che devono essere visualizzati.

Answer 6

Due cose mi suggeriscono:

Uno: Leggi su IRB (o dello script / console per rotaie). Una pratica comune di sviluppo in linguaggi dinamici è quello di provare frammenti di codice all'interno di un interprete di "live" (come IRB o la console rotaie). Questa pratica risale ai primi linguaggi dinamici come Smalltalk e Lisp. Ruby-debug è anche molto utile per la risoluzione dei problemi e sarebbe stato un modo molto semplice per capire l'errore nel tuo esempio.

Due: Leggi su "duck typing". "tipi" e variabili lavorare un po 'diverso in Ruby che molte persone si aspettano loro di. A quanto ho capito, una variabile come user.id non ha un "tipo". Il valore indicato da user.id non avere un tipo, ma la variabile stessa non lo fa. Credo che è parte del motivo per cui non c'è strumento che ti avrebbe detto che cosa il vostro errore è stato prima di avviare il programma. Confrontando queste due variabili non è un errore perché le variabili non hanno un tipo. user.id stava indicando un numero intero a quel punto del programma, ma sarebbe perfettamente legale per assegnare user.id per puntare a una stringa, a quel punto che il confronto avrebbe reso molto più senso. : -)