Czy przydział w klauzuli warunkowej ma dobry styl rubinowy?

Question

Aby napisać bardziej zwięźle, zamiast to zrobić:

test_value = method_call_that_might_return_nil() 
if test_value 
    do_something_with test_value 
end 

Byłem przypisywania w warunkowej:

if test_value = method_call_that_might_return_nil() 
    do_something_with test_value 
end 

Czy to zły styl? Wciąż jeszcze bardziej zwięzły Składnia

do_something_with test_value if test_value = method_call_that_might_return_nil() 

jest zabronione, jak omówiono in another SO question i pozostaje w ten sposób w 1,9 według Matz (http://redmine.ruby-lang.org/issues/show/1141).

Biorąc pod uwagę możliwe pomyłki przydziału i porównania, czy to utrudnia czytanie kodu?

Answer 1

To pytanie zostało niedawno zapytane QUITE, a wszystkie odpowiedzi są nieaktualne.

To jest wyraźnie DOBRY styl do używania przydziałów w warunkowych. Jeśli to zrobisz, zawiń warunek w nawiasach.

# Bad 

if value = Settings.get('test_setting') 
    perform_action(value) 
end 

# Okay, but uncommon and verbose 

value = Settings.get('test_setting') 
if value 
    perform_action(value) 
end 

# Good 

if (value = Settings.get('test_setting')) 
    perform_action(value) 
end 

See the community style guide for more information

Wcześniej przyjął odpowiedź mówi się użyć słowa kluczowego and. Nigdy nie używaj słów kluczowych and lub w ruby. Jest to również w przewodniku po stylach i istnieją bardzo dobre logiczne powody, aby ich nie używać.

Answer 2

Tak, powiedziałbym, że to zły styl z powodu możliwego zamieszania między przydziałem a porównaniem. To tylko jedna linia do przypisania, a następnie do testowania, i pozwala uniknąć sytuacji, w której ktoś w przyszłości pomyśli, że to był błąd, i zamiast tego załatać go w celu użycia ==.

Answer 3

Jeden nieco powszechne idiom jest użycie and, który będzie wyglądał mniej więcej tak:

tmp = method_call_that_might_return_nil and do_something_with tmp 

Inną możliwością byłoby nazwać #nil? wyraźnie, że sposób intencja staje się nieco jaśniejszy; W szczególności jest to naprawdę oczywiste, że faktycznie oznaczało przypisać zamiast porównania:

unless (tmp = method_call_that_might_return_nil).nil? 
    do_something_with tmp 
end 

Answer 4

kod Zwięzłe niekoniecznie jest lepszy kod. Przydatność jest przydatna, gdy poprawia komunikację zamierzonego zachowania kodu od autora do przyszłych opiekunów. Myślę, że większość z nas pochodzi ze środowisk, w których mieliśmy przypadkowe zadania w blokach if (kiedy chcieliśmy mieć porównanie równości), że preferujemy style, w których absolutnie jasne jest, że przypisanie ma znaczenie, a nie porównanie. Wymieniony już identyfikator .nil? ma tę właściwość i uważam, że jest to czystsze niż posiadanie gołego zadania w stanie if. Naprawdę jednak nie widzę szkody w posiadaniu dodatkowego wiersza kodu dla zadania.

Answer 5

Programiści C robią to bardzo. Nie widzę z tym problemu w Ruby, o ile jest jasne, co się dzieje.

Answer 6

Myślę, że wszystko w porządku. Awersja do przypisania w warunku wynika z faktu, że pominięty kluczowy skok podczas wpisywania == zmienia porównanie w niezamierzone zadanie. Stylistyka zakazu używania przydziału w stanie sprawia, że ​​wypadki te wyróżniają się jak na oko (a czasem na język, jak w C, gdzie można wykonać wiele kompilatorów, aby wysłać ostrzeżenie, jeśli napotkają zadanie w stanie). Z drugiej strony, testy również powodują, że takie wypadki się wyróżniają. Jeśli twój kod jest dobrze objęty testami, możesz rozważyć odrzucenie takich zakazów.

Answer 7

Sposób programowania funkcjonalnego polega na użyciu andand. Jest to czytelny sposób łączenia łańcuchów wywołań metod, dzięki czemu zero w środku zatrzymuje łańcuch. Twój przykład będzie wyglądał następująco:

method_call_that_might_return_nil.andand.tap {|obj| do_something_with obj} 
## or, in the common case: ## 
method_call_that_might_return_nil.andand.do_something