Scala podkreśla w nazwach

Question

Przeczytałem wiele wytycznych dotyczących stylu i innych zasobów, stwierdzając, że używanie znaków podkreślenia w metodzie/zmiennej/innych nazwach jest złym pomysłem.

Jakie są tego techniczne powody?

Jestem bardzo przyzwyczajony do np. poprzedzanie funkcji pomocnika za pomocą _. Są też funkcje, które powinny być prywatne, które chcę upublicznić, aby uzyskać do nich dostęp za pośrednictwem REPL. Inne konwencje nazewnictwa, takie jak użycie sufiksu "pomocnika", wydają się tylko kłopotliwe.

Wszelkie uwagi będą mile widziane!

Answer 1

Operator wieloznaczny _ jest używany intensywnie w Scala. A więc:

xs map (_.x) // Call the x method of every element 
xs map (_x) // Pass every element through the _x method 

jest mylące. Trzeba bardzo uważnie sprawdzić, czy podkreślenie zostało dodane.

jednak podkreślenia wewnętrzne są trudniejsze mylić:

xs map (my_method) // No similar form where _ stands for the list element 

więc są mniej problematyczne, ale podkreślenia nadal przyciągają wzrok trochę, gdy ktoś szuka zamknięć. Prawdopodobnie dlatego są zniechęceni, ale szczerze mówiąc, używam ich przez cały czas, szczególnie w takich rzeczach, jak implicite defs i wewnętrzne zmienne, w których nie będą mieli dużego lub żadnego kontaktu w interfejsie.

Answer 2

Myślę, że te specyfikacje mówią tylko o podkreśleniach w nazwach.

w jaki (rozsądny) sposób należy napisać następujące, jeśli nie w ten sposób?

object getterSetter { 
    var _variable: Option[Double] = None 
    def variable = _variable 
    def variable_=(newVal: Double) { _variable = Some(newVal) } 
} 

Myślę, że powodem dla camelCase zamiast embedded_underscores jest po prostu to, że korzysta z java i podczas pracy z bibliotekami Java, konsystencja mogą być przechowywane tylko tak.

Answer 3

Tylko znam powód, dla którego unikam podkreśleń w nazwach: są one ważną częścią składni Scala, która pojawia się w każdym miejscu. Pewnie, możesz można umieścić je w nazwach, ale to ma tendencję do spowolnienia ludzkiego parsera w moim doświadczeniu.

Ale muszę przyznać, że czasami używam przedrostka podkreślenia dla zmiennych prywatnych w obiektach zmiennoprzecinkowych, jeśli chcę mieć niewytłumaczoną nazwę dla publicznych metod. Byłoby miło, gdybyśmy mogli używać liczb pierwszych (foo), takich jak Haskell, ale myślę, że byłoby to leksykalnie trudne.

Answer 4

Oprócz _ używany na całym języku nie tylko jako zamiennika ale również jako części API publicznych jak w krotek (someTuple._1 etc) jest również specjalnie interpretowane przez kompilator w niektórych przypadkach. Na przykład w seterach, które muszą być poprzedzone przyrostkiem _= lub jednoargumentowymi operatorami, które muszą być poprzedzone prefiksem unary_.

Wszystko to sprawia, że ​​naprawdę łatwo jest użyć "specjalnej nazwy" przez przypadek lub źle zinterpretować "zwykłą nazwę", gdy ktoś użył czegoś podobnego, ale nie identycznego z "specjalną nazwą". Nie ma znaczenia, czy stało się to przez przypadek, czy z powodu braku wiedzy, ale kiedy to nastąpi, prawdopodobnie spędzisz kilka godzin szukając błędu. Więc nie używaj ich, chyba że naprawdę musisz.DSL są jak zawsze wyjątkiem.