Руководство по стилю Scala для подчеркивания идентификаторов

Question

Я принял от многих других языков, что подчеркивание имеет столько же свободы, сколько алфавиты в идентификаторе.Отсюда _v и v_.Кроме того, в качестве конечных подчеркиваний рекомендуется , чтобы избежать неоднозначности с зарезервированными ключевыми словами (class_, case_).

val abc_=0
<console>:1: error: '=' expected but integer literal found.
       val abc_=0

Подчеркивает, что является важной частью системы набора Scala, что являетсярекомендуемый способ использовать их в идентификаторах , чтобы парсер и человек могли быть счастливы?Каковы все возможные двусмысленности, которые приносят идентификаторы с подчеркиванием?

Ведущие пробелы, кажется, добавляют путаницу _class вместо class_.

---

Смежные вопросы:

• Для чего используются символы подчеркивания в Scala?
• Символы подчеркивания Scala в именах

Answer 1

Конечные подчеркивания - плохая идея, потому что такие вещи, как x_+, сами по себе являются допустимыми именами переменных.Ни в коем случае не используйте конечные подчеркивания.

Ведущие подчеркивания - не самая плохая идея, но визуально разобрать такие вещи, как _myfunc _, все равно сложно.Существует соглашение о том, что закрытые члены, содержащие аргументы конструктора с одинаковыми именами, начинаются с _: class X(x: Int) { private var _x = x }.Моя рекомендация не делай этого .Вы просите путаницы.Используйте myX или theX или xLocal или xi или что-то для внутренней переменной.Тем не менее, если вы делаете с _x, у вас будет хорошая компания;люди будут склонны понимать, что вы имеете в виду.

Подчеркивания в имени не используются широко, так как случай с верблюдом является стандартом.Исключение, которое я делаю, состоит в том, что я использую подчеркивания в неявных определениях, которые не должны использоваться вручную, и вместо этого указываю, почему происходит преобразование: tuple2_can_expand может добавить метод expand для преобразования Tuple2 вTuple3, например.

Answer 2

Есть только одно место, которое вам нужно подчеркнуть в идентификаторах: между буквенно-цифровыми символами и другими.Фактически, это именно то, что происходит в вашем случае: парсер думает, что вы объявляете val abc_=, а после него нет =!Чаще всего используются методы «сеттера»:

def prop: String // or some other type
def prop_=(v: String)

Я также видел predicate_? вместо более похожих на Java isPredicate.

keyword_ не частоиспользуется, но если вы используете их, не экономьте на пробелах.Напишите, например, val abc_ = 0.Но в этом отношении val abc = 0 также более читабелен, чем val abc=0, поэтому в любом случае у вас должно быть свободное место.Как говорит Рекс Керр, _privateVariable является приемлемой, но не рекомендуемой практикой.