Скала подчеркивает в именах

Question

Я прочитал несколько руководств по стилю и другие ресурсы, утверждая, что использование символов подчеркивания в именах методов / переменных / других имен - это плохая идея.

Каковы технические причины этого?

Я очень привык, например. добавление вспомогательных функций с помощью _. Есть также функции, которые должны быть приватными, и я хочу сделать их общедоступными, чтобы я мог получить к ним доступ через REPL. Другие соглашения об именах, такие как использование вспомогательного суффикса, просто кажутся громоздкими.

Любые мысли приветствуются!

Answer 1

Оператор подстановки _ интенсивно используется в Scala.Итак:

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

сбивает с толку.Вы должны посмотреть очень внимательно, чтобы увидеть, стоит ли ставить подчеркивание.

Однако, внутренние подчеркивания сложнее спутать:

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

Так что это менее проблематично, но подчеркивание все же немного привлекает внимание, когда кто-то ищет замыкания.Вероятно, поэтому они не одобряются, но, честно говоря, я использую их все время, особенно в таких вещах, как неявные определения и внутренние переменные, где они не будут иметь большого или какого-либо воздействия на интерфейс.

Answer 2

Я знаю только причину, по которой я избегаю подчеркивания в именах: они являются важной частью синтаксиса Scala, который появляется повсюду.Конечно, вы можете поместить их в имена, но в моем опыте это имеет тенденцию замедлять синтаксический анализатор.

Но я должен признаться, что иногда я использую префикс подчеркивания для частных переменных в изменяемой переменнойобъекты, если я хочу имя без подчеркивания для открытых методов.Было бы неплохо, если бы мы могли использовать простые числа (foo '), такие как Haskell, но я думаю, что это будет лексически сложно.

Answer 3

В дополнение к _, используемому во всем языке, не только в качестве подстановочного знака, но и как части публичных API, таких как в кортежах (someTuple._1 и т. Д.), Он также интерпретируется специально в некоторых случаях компилятором. Например, в setters , к которым необходимо добавить суффикс _=, или в унарных операторах , к которым должен быть добавлен unary_.

.

Все это делает очень простым случайное использование «специального имени» или неправильное толкование «обычного имени», когда кто-то использует нечто подобное, но не совсем то же самое, что «специальное имя». Не имеет значения, произошло ли это случайно или из-за недостатка знаний, но когда это произойдет, вы, вероятно, потратите пару часов на поиск ошибки. Так что не используйте их, если вам действительно не нужно. DSL как всегда являются исключением.

Answer 4

я думаю, что эти спецификации говорят только о подчеркивании в именах.

каким (нормальным) способом вы должны написать следующее, если не так?

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

я думаю, что причина camelCase вместо embedded_underscores в том, что java использует это, и при работе с библиотеками java согласованность может поддерживаться только таким образом.