byłem utworzenia symboli w kodzie jak:Ruby konfiguracja symbol
"name_of_symbol".to_sym
Jednak mój główny inżynier podniósł go podczas przeglądu kodu jako złych praktyk i poprosił mnie, aby ustawić symbole, takie jak:
:"name_of_symbol"
Kiedy zapytałem go, dlaczego? Powiedział, że to zła praktyka, ale kiedy zapytałem, z jakiego powodu właśnie to powiedział, to nie jest satysfakcjonująca odpowiedź. Więc jak to jest? Czy jest jakaś różnica?
Inne odpowiedzi twierdzą, że prawidłowo :"foo bar" przewyższa "foo bar".to_sym ponieważ jest jaśniejsza, lepiej wyraża swoją wolę, jest bardziej czytelny, szybciej itd. Ale jest jeszcze jeden powód: "foo bar".to_sym polega na String#to_sym metody, a istnieje możliwość (chociaż zdalne), że ta metoda może zostać przedefiniowana. Jest to jedyny nie kosmetyczny powód, dla którego :"foo bar" jest z zasady lepszą praktyką.
To prawda, chociaż na nowo zdefiniowanie 'to_sym' na pewno spowodowałoby zamieszki na całym świecie. –
To na pewno by. Jest to w zasadzie czysto teoretyczny argument. –
Dwukropek wskazuje symbol. Nie nazwałbym tego złym ćwiczeniem tak bardzo, jak niekonwencjonalną praktyką, która może sprawić, że kod będzie trochę trudniejszy do zrozumienia.
Wiem, że :"Some weird stuff" jest legalne, ale nie podoba mi się to, osobiście wolałbym używać :Some_weird_stuff i zostawić razem wszystkie cytaty - używając cytatów, kiedy nie musisz, po prostu dodajesz hałas - jestem bardzo przeciw hałasowi. Hałas to zła praktyka, sprawia, że zrozumienie trwa dłużej.
Czasami, gdy dopasowujesz elementy, które przychodzą jako łańcuchy, ale dla spójności chcesz symboli, wtedy nie masz wielkiego wyboru, ale wolę nie zadawać tego pytania, FWIW.
Kiedy masz składniowo czystych symboli można użyć składni
{ thing: "value" }
, który jest radość i bardzo jasne i czytelne.
Co ciekawe, choć:
irb
> class String ; def to_sym ; puts "bob" ; end ; end
=> nil
> "fred".to_sym
bob
=> nil
> :"fred"
=> :fred
Więc punkt Borisa jest ważny jeden.
Powinienem chyba zauważyć w moim pytaniu, że jest to czas, w którym symbol jest ustawiany dynamicznie jak array.each {| s | : "# {s}" } więc moim zdaniem będzie to "# {s}". To_sym –
Masz ciąg znaków i robisz: "# {s}" - osobiście bym idź z to_sym, interpolując ciąg, a następnie wywołując to_sym w locie w tle ... trochę bezsensowne, myślę :) – Ghoti
Innymi słowy, nie rób ':" # {s} "' lub '" # {s} ".to_sym", po prostu wykonaj 's.to_sym' – Ajedi32
Jeden to literał Symbol, drugi to literatura String, na którą można się nazywać metodą.
Osobiście uważam, że to dziwne, aby napisać String gdy chodziło Ci napisać Symbol, tylko wtedy natychmiast przekształcić String w Symbol. Dlaczego nie napisać w pierwszej kolejności Symbol? To sprawia, że twoje intencje są znacznie wyraźniejsze.
To nie jest dziwne, na przykład, jeśli jakaś metoda zwraca ciąg znaków, wtedy 'method_which_returns_a_string.to_sym' jest drogą do przejścia –
@RustamA. Gasanov: ale nie o to chodzi. Pytanie dotyczy użycia literału symbolicznego bezpośrednio w przeciwieństwie do literału literowego, który następnie przekształca się w symbol. Oczywiście zupełnie inne pytanie może mieć zupełnie inną odpowiedź. –
To wydaje się być kwestią preferencji, ale widzę, jak pisanie symbolu jako symbolu jest dużo bardziej przejrzyste niż pisanie ciągu znaków, który zmienia się w symbol.
Także cudzysłów nie jest potrzebny, gdy używasz snake_case.
"name_of_symbol".to_sym:"name_of_symbol":name_of_symbolJest to kwestia stylu, ale wydaje mi się, że 3 jest najbardziej czytelny i zwięzły wersja z trzech. Jeśli "najlepsza praktyka" oznacza łatwą lekturę, a zatem utrzymanie, powiedziałbym 3 wygrane.
Wydaje się, że jest to konwencja w miejscu pracy, a nie kwestia bycia "złą praktyką". Konwencje są po prostu tym, nie ma potrzeby dyskutować (dlaczego nazywamy drzewo "drzewem", a nie "glugotem", ponieważ zgodziliśmy się na użycie "drzewa"). Niektórzy mogą argumentować "czytelność" - ale bez przeprowadzenia faktycznych badań naukowych, które udowodniłyby, że: składnia sym jest łatwiejsza do odczytania, to tylko twierdzenie. Z drugiej strony, gdyby facet odmówił udzielenia wyjaśnienia, to jest coś, z czym nie możemy ci pomóc :(Moje zdanie: zdefiniuj symbol z ': sym', ale dla jawnej konwersji na symbol użyj' .to_sym'. –
To nie jest Zła praktyka Zła praktyka polega na tym, że nie potrafisz czegoś wyjaśnić, gdy jesteś liderem zespołu przy projekcie –
To także nie jest dobra praktyka, pamiętaj, że nie cytujesz cudzysłowów, jeśli twój symbol nie zawiera białych znaków i innych znaków. znaki, które mogą być niejednoznacznie interpretowane przez parser Ruby, więc ': foo_bar' jest w porządku bez cytatów, potrzebujesz tylko cytatów dla': 'foo bar "'. –