Ruby: se variabile vs if variable.nil?

Scrivi cosa intendi. Significa ciò che scrivi.

Facciamo un test diverso. .vowel?

if char == 'a'
   # do stuff
end

vs

if char.vowel?
   # do stuff
end

Ora è ovvio che questi non fanno la stessa cosa. Ma se ti aspetti solo char come a o b , funzionerà. Ma confonderà il prossimo sviluppatore - il secondo blocco verrà inserito per le condizioni in cui il char è [eiou] anche. Ma per a , funzionerà correttamente.

Sì, è il caso che nil e false siano gli unici valori falsy in Ruby. Tuttavia, se stai testando per nil testando per nil || false , questo non è ciò che intendi.

Significa che il prossimo sviluppatore (che capita di essere un pazzo assassino che conosce il tuo indirizzo di casa) leggerà il codice e si chiederà perché false dovrebbe andare anche lì.

Scrivi il codice che esattamente cosa intendi.

Considera quanto segue:

response = responses.to_a.first

Questo restituirà il primo elemento di responses o nil . Quindi, poiché le istruzioni condizionali trattano nil come false possiamo scrivere:

response = responses.to_a.first
if response
  # do something ('happy path')
else
  # do something else
end

Che è più leggibile di:

if response.nil?
  # do something else
else
  # do something ('happy path')
end

Il modello if (object) è molto comune nel codice Ruby. Porta anche bene al refactoring, ad esempio:

if response = responses.to_a.first
  do_something_with(response)
else
  # response is equal to nil
end

Ricorda anche che un metodo Ruby restituisce nil per impostazione predefinita. Quindi:

def initial_response
  if @condition
    @responses.to_a.first
  else
    nil
  end
end

può essere semplificato in:

def initial_response
  if @condition
    @responses.to_a.first
  end
end

Quindi possiamo ulteriormente refactoring:

if response = initial_response
  do_something_with(response)
else
  # response is equal to nil
end

Ora puoi affermare che restituire nil non è sempre l'idea migliore, poiché significa controllare per nil ovunque. Ma quello è un altro bollitore di pesce. Dato che il test per la presenza o assenza di oggetti è un requisito così frequente, la verità degli oggetti è un aspetto utile di Ruby, anche se è sorprendente per i neofiti del linguaggio.

Non solo if variable.nil? legge più come un linguaggio naturale, ma protegge anche da un programmatore assegnandogli accidentalmente un valore false e cade nella tua istruzione if , dal momento che Ruby è un linguaggio con caratteri generici.

Idiomaticamente, unless variable è preferibile a if !variable . Le dichiarazioni di if negate sono spesso considerate un odore di codice in quanto è più facile perdere la negazione durante la schiumatura.

L'immagine più grande qui è che facendo nil assegni come questo è anche un po 'di odore di codice. Per OO corretto, mirare a utilizzare il modello di oggetto nullo in modo che questo tipo di controllo non sia mai necessario. link

Dì agli oggetti cosa fare, non chiedere loro cosa sono. Questo è talvolta noto come tell non chiedere