Czy zostawiasz nawiasy wewnątrz czy na zewnątrz w Rubim? [Zamknięte]


Odpowiedzi:


95

Z elementów stylu rubinowego

Ruby pozwala ogólnie pominąć nawiasy, aby oprzeć się tej pokusie.

Nawiasy ułatwiają śledzenie kodu. Ogólny styl Ruby polega na ich używaniu, z wyjątkiem następujących przypadków:

  • Zawsze pomijaj puste nawiasy
  • Nawiasy można pominąć w pojedynczym poleceniu otoczonym ogranicznikami ERb - znaczniki ERb zapewniają, że kod jest nadal czytelny
  • Wiersz będący pojedynczym poleceniem i pojedynczym prostym argumentem można zapisać bez nawiasów. Osobiście uważam, że robię to coraz rzadziej, ale nadal jest to doskonale czytelne. Zwykle nie lubię pojedynczych wierszy w zwykłym kodzie ruby, które mają wiele argumentów i nie zawierają nawiasów.
  • Wiele języków specyficznych dla domeny opartych na Ruby (takich jak Rake) nie używa nawiasów, aby zachować bardziej naturalny charakter wypowiedzi.

27

Używam parenów jako komentarzy, aby pomóc przyszłemu mi ... który prawdopodobnie będzie miał mniej komórek mózgowych niż obecny ja :-)

Nie ma nic gorszego niż przyjrzenie się kodowi, który napisałeś 2 lata temu i niezrozumienie go, aby coś zepsuć podczas modyfikacji.

Jeśli pareny uratują mnie w przyszłości kilka minut (lub godzin) w przyszłości, dodam tyle, ile potrzeba, aby stwierdzenie było krystalicznie jasne.


2
+1 „Używam parenów jako komentarzy, aby pomóc przyszłemu mnie ... który prawdopodobnie będzie miał mniej komórek mózgowych niż obecny ja :-)” To jest TAKIE prawdziwe i dokładnie dlaczego to robię. Jest to również miłosierne dla każdego, kto mnie śledzi i musi użyć mojego kodu. Krótko mówiąc, jest to kwestia konserwacji.
Tin Man

9

Pomijam je, gdy robię rzeczy DSL, takie jak t.column lub has_many w railsach. Przez resztę czasu generalnie sprowadza się to do jasności i prawdopodobnie jest to równy podział.


8

Wydaje mi się, że robię jedno i drugie, ale zdecydowanie zachowuję je, jeśli zwiększa to czytelność i unika stwierdzeń, które wyglądają na niejednoznaczne.


8

Jeśli masz na myśli wywołania funkcji, zawsze umieszczam nawiasy, ponieważ zawsze jest to łatwiejsze do odczytania. Jeśli masz na myśli warunki (if, while), umieszczam nawiasy tylko wtedy, gdy są konieczne.


2
Zgadzam się. Na przykład w php mogę szybko dostrzec zmienną po przedrostku $ .. w javascript mogę zrekonstruować funkcję za pomocą nawiasów (). W Rubim różnica między var lub func (bez nawiasów) nie zawsze jest łatwa do zauważenia.

7

Staram się je pominąć, jeśli to w ogóle możliwe. Myślę, że ułatwia to czytanie kodu (ogólnie mówiąc).


4

Cokolwiek jest zwykle bardziej czytelne.

Ale zawsze używam nawiasów, gdy zagnieżdżam wywołania funkcji w parametrach innych


2

Zwykle pomijam je podczas wykonywania asercji, takich jak assert_equal. Może po to, aby uczynić ją podobną do języka specyficznego dla domeny.


1

Jeśli programujesz od dłuższego czasu, prawdopodobnie będziesz mieć „swędzenie” na dodawanie nawiasów, aw wielu przypadkach są ku temu dobre powody.

Moim zdaniem kod jest łatwiejszy dla oczu i jeszcze nie napotkałem problemu - jeśli będziesz potrzebować nawiasów, będziesz wiedział o tym wcześniej, zanim będziesz musiał uruchomić skrypt debugowania.


4
„Mój nauczyciel mówi mi, że to nieuniknione”. To jest i może być trudne do debugowania. Zalecam ich używanie, aby uniknąć niejednoznacznego przypisywania parametrów.
Tin Man,

Ocena negatywna jako „łatwiejsza dla oczu” jest przez IMO kiepskim powodem do pominięcia nawiasów wokół argumentów funkcji.
Marcello Romani

2
rozmawiając z tłumem non-parens, napotkałem ten problem if owner.is_a? thing //worked fine if owner.is_a? thing && x > 1 //not fine pewnego dnia , uczę się ruby ​​dopiero od kilku tygodni i tam, gdzie pracuję, używa się najmniejszej możliwej liczby znaków, a jeśli pochodzisz z innego języka, jest nauka krzywa, aby wiedzieć, kiedy przekazujesz niejawny skrót, tablicę symboli, przechodząc do symboli do funkcji ... nie jestem fanem.
Mega Man

@MegaManif owner.is_a? thing and x > 1
anna328p

1
@DmitryKudriavtsev andnie ma tego samego pierwszeństwa operatora, &&co
Mega Man,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.