Подтвердить что ты не робот

Использование специальных символов в именах функций

В Ruby стандартное соглашение заключается в использовании вопросительного знака в конце имени метода, чтобы указать, что метод возвращает логический результат:

[].empty?   #=> true 

Другим стандартным соглашением является завершение имени метода с восклицательным знаком, если метод является деструктивным (то есть он изменяет исходные данные):

mylist.sort! # sort mylist in-place

Недавно я видел те же самые соглашения, что и на Схеме. Что заставляет меня задуматься, что другие языки используют/поддерживают это соглашение? Существуют ли другие специальные символы, которые обычно используются для обозначения этими или другими языками?

4b9b3361

Ответ 1

Ответ - это, конечно же, язык (и языковая культура).

Например, в зависимости от языка подходят все следующие: empty-p, empty?, empty, is_empty или isEmpty. (Эти примеры, конечно, не включены).

Примеры в исходном вопросе исходят от Ruby, где такое использование? а также! для завершения имен методов, при необходимости, принимаются. Это признание приходит из 1) легкодоступного в качестве символьных терминаторов в грамматике 2) использования? а также! в стандартной библиотеке. Однако следует отметить, что! не используется повсеместно, чтобы подразумевать "побочный эффект" и обычно присутствует только в альтернативных формах: save/save!, sort/sort!, и т.д. Существует огромное количество методов, которые выполняют побочные эффекты, которые не имеют! Приставка.

Лично, если бы я разрабатывал язык, я бы позволил?,! и 'быть допустимыми неупорядоченными конечными символами в именах символов. Несмотря на то, что некоторые языки допускают полное экранирование символов, например Scala, такие символы обычно избегают, потому что это боль, чтобы процитировать их для использования.

// in Scala, esp. with Java-compat, the last form is generally used although
// the first two are perfectly valid -- do what makes sense in the language
foo.`empty?`
foo.empty_?
foo.isEmpty

Когда в Риме...

  • Scala - `empty?` или empty_? (не часто)
  • C/С++/JS/Java/Python/Perl - нет? или! в идентификаторах; JS/Java разрешает $; $- сигл в Perl
  • C/С++/Perl/JS - поднимается в воздух?
  • С# - IsEmpty (метод или свойство) или Пусто (свойство)
  • Python - is_empty или isEmpty per Guido-guide (хотя обычно протокол __len__: if not len(foo): "empty!")
  • Java - isEmpty per Language Guide
  • Ruby - специальный трейлинг? а также! (Цитирую?)
  • JS - доступ косвенного идентификатора: obj [ "empty?" ] (не является общим для этого)
  • "Lisp" (обычный): empty-p для предиката; варианты чтения/цитирования

Рад видеть исправления и/или дополнения - это всего лишь падение в ковше.

Ответ 2

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

Вариант ? можно так же легко выполнить с помощью isEmpty() и ! с sortInPlace().

Английский язык очень адаптивный, даже без знаков препинания.

В любом случае мои языки выбора (C и Java) используют пунктуацию для всех видов других вещей. Наличие в идентификаторах также сделает лексический анализ кошмаром.

Ответ 3

Превращение "@" в имя метода (или любой идентификатор) в С# позволяет вам назвать этот метод ключевым словом с нормальным резервированием.

void null() {}
// Invalid token 'null' in class, struct, or interface member declaration

void @null()
// compiles

Не делай этого; это главным образом для машинного кода, такого как наборы данных. Страница MSDN по этой теме.

Ответ 4

Если вы считаете Javascript как язык, многие фреймворки, похоже, используют символ "$" для обозначения "Селектор"; Например, можно использовать $("id-of-some-item") в Prototype.js или $("#id-of-some-item") в jQuery, чтобы выбрать тег, который был написан <div id="id-of-some-item">. Использование этих функций выбора на самом деле довольно сложное и мощное (если вам интересно, посмотрите их подтверждающую документацию на prototypejs.org и jquery.com), но они сводятся к тому, что я считаю семантически похожим на то, что вы указано.

Опять же, предполагается, что вы считаете Javascript как язык.