Разве плохо использовать символы Юникода в именах переменных? [закрыто]

Недавно я пытался реализовать алгоритм ранжирования AllegSkill для Python 3.

Вот как выглядит математика:

_{Нет, правда.}

Это то, что я написал:

t = (µw-µl)/c  # those are used in
e = ε/c        # multiple places.
σw_new = (σw**2 * (1 - (σw**2)/(c**2)*Wwin(t, e)) + γ**2)**.5

Я действительно думал , что он несчастлив в Python 3 не принимать √или в ²качестве имен переменных.

>>> √ = lambda x: x**.5
  File "<stdin>", line 1
    √ = lambda x: x**.5
      ^
SyntaxError: invalid character in identifier

Я сошел с ума? Должен ли я прибегнуть к ASCII только версии? Почему? Не будет ли версия ASCII выше всего сложнее проверить на эквивалентность с формулами?

_{Имейте в виду, я понимаю, что некоторые символы Unicode очень похожи друг на друга, а некоторые как (или это ▗▖) или ╦ просто не могут иметь никакого смысла в написанном коде. Тем не менее, это вряд ли имеет место для математики или стрелок.}

По запросу, версия только для ASCII будет выглядеть примерно так:

winner_sigma_new = ( winner_sigma ** 2 *
                    ( 1 -
                     ( winner_sigma ** 2 -
                       general_uncertainty ** 2
                     ) * Wwin(t,e)
                    ) + dynamics ** 2
                   )**.5

... за каждый шаг алгоритма.

Я твердо считаю , что просто заменить σс sили sigmaбыло бы глупо, граничащим с глупым.

Каков потенциальный выигрыш? Ну что ж, посмотрим ...

• Это улучшает читабельность? Нет, ни в малейшей степени. Если бы это было так, оригинальная формула, несомненно, использовала бы и латинские буквы.

• Улучшает ли это возможность записи? На первый взгляд да. Но на втором нет. Потому что эта формула никогда не изменится (ну, «никогда»). Обычно нет необходимости ни изменять код, ни расширять его с помощью этих переменных. Таким образом, возможность записи - только один раз - не проблема.

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

Но греческий не проблема. Неописательные, однобуквенные идентификаторы

Поэтому либо сохранить оригинальную запись ... В конце концов, если язык программирования делает поддержку Unicode в идентификаторах, так что нет никакого технического барьера. Или используйте значимые идентификаторы. Не просто замените греческие глифы латинскими. Или арабские, или хинди.

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

А как насчет альтернативы и просто наверх //µ = uи написать все в ascii?

Этот аргумент предполагает, что у вас нет проблем с набором юникодов и чтением греческих букв

Вот аргумент: вы хотели бы пи или циркулярное соотношение?

В этом случае я бы предпочел pi вместо циркулярное отношение, потому что я узнал о pi с тех пор, как я учился в начальной школе, и я могу ожидать, что определение pi хорошо укоренено всеми программистами, достойными его внимания. Поэтому я не прочь напечатать π, чтобы обозначить циркулярное соотношение.

Тем не менее, как насчет

winner_sigma_new = ( winner_sigma ** 2 *
                    ( 1 -
                     ( winner_sigma ** 2 -
                       general_uncertainty ** 2
                     ) * Wwin(t,e)
                    ) + dynamics ** 2
                   )**.5

или же

σw_new = (σw**2 * (1 - (σw**2)/(c**2)*Wwin(t, e)) + γ**2)**.5

Для меня обе версии одинаково непрозрачны, как piи πесть, за исключением того, что я не изучал эту формулу в начальной школе. winner_sigmaи Wwinничего не значит для меня или кого-либо еще, кто читает код, и использование ни того, ни другого σwне делает его лучше.

Таким образом, использование описательных имен, например total_score, winning_ratioи т. Д., Значительно повысит читабельность, чем использование имен ascii, которые просто произносят греческие буквы . Проблема не в том, что я не могу читать греческие буквы, но я не могу связать символы (греческие или нет) со «значением» переменной.

Вы , конечно , поняли эту проблему самостоятельно , когда вы прокомментировали: You should have seen the paper. It's just eight pages.... Проблема заключается в том, что если вы называете свои переменные именами на бумаге, в которой для краткости выбираются однобуквенные имена, а не для удобства чтения (независимо от того, являются ли они греческими), то люди должны будут прочитать статью, чтобы иметь возможность связать буквы "смысл"; это означает, что вы ставите искусственный барьер, чтобы люди могли понимать ваш код, и это всегда плохо.

Даже когда вы живете в мире только для ASCII, оба a * b / 2и alpha * beta / 2одинаково непрозрачный рендеринг height * base / 2формулы площади треугольника. Нечитаемость использования однобуквенных переменных растет экспоненциально по мере усложнения формулы, и формула AllegSkill, безусловно, не является тривиальной формулой.

Переменная с одиночными буквами приемлема только как простой счетчик циклов, независимо от того, являются ли они греческими однобуквенными или односимвольными ascii, мне все равно; никакие другие переменные не должны состоять только из одной буквы. Мне все равно, если вы используете греческие буквы для своих имен, но когда вы действительно используете их, убедитесь, что я могу связать эти имена со «смыслом» без необходимости читать произвольную статью где-то еще.

В начальной школе я определенно не возражал бы видеть математические выражения с использованием таких символов, как: +, -, ×, ÷, для базовой арифметики, а √ () - функция с квадратным корнем. После окончания начальной школы я не возражаю против добавления новых блестящих символов: the для интеграции. Обратите внимание на тенденцию, это все операторы. Операторы используются гораздо интенсивнее, чем имена переменных, но они реже используются для совершенно другого значения (в случае, когда математики повторно используют операторы, новое значение часто все еще содержит некоторые основные свойства старого значения; это не так для при повторном использовании имен переменных).

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

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

Лично я был бы рад видеть заднюю часть исходного кода только для ASCII.

Да, ты сошел с ума. Я бы лично сослался на номер бумаги и номер формулы в комментарии и написал все прямо в ASCII. Тогда любой желающий сможет соотнести код и формулу.

Я бы сказал, что использование имен переменных Unicode - плохая идея по двум причинам:

1. Они ПИТА, чтобы напечатать.

2. Они часто выглядят почти так же, как английские буквы. Это та же самая причина, почему я ненавижу видеть греческие буквы в математической записи. Попробуйте рассказать Ро отдельно от р. Это не просто.

В этом одном случае, сложная математическая формула, я бы сказал, пойти на это.

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

Сказать , что, если я когда - либо , чтобы поддерживать М и сг в трясину стандартный код , который вы завещал мне, я будет узнать, где вы живете ...

• Pro: выглядит красиво
• Против: символы Юникода и, следовательно, все значение может потеряться в цепочке инструментов (редактор, средство форматирования кода, контроль версий, старый компилятор)

Насколько велик риск для вас? Перевес перевешивает риск?

Когда-нибудь в не столь отдаленном будущем мы все будем использовать текстовые редакторы / IDE / веб-браузеры, которые облегчают написание редактируемого текста, включая символы классического греческого алфавита и т. Д. (Или, может быть, мы все научились использовать это «скрытое» «Функциональность инструментов, которые мы используем в настоящее время ...)

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

(Кстати, причина, по которой вы можете иметь греческие символы, но не квадратные корни в идентификаторах Python, проста. Греческие символы классифицируются как буквы Unicode, но квадратный корень не является буквой; см. Http://www.python.org / dev / peps / pep-3131 / )

Вы не сказали, какой язык / компилятор вы используете, но обычно для имен переменных правило состоит в том, что они должны начинаться с буквенного символа или подчеркивания и содержать только буквы, цифры и подчеркивание. Юникод √ не будет считаться буквенно-цифровым, поскольку он представляет собой математический символ вместо буквы. Тем не менее, σ может быть (поскольку он в греческом алфавите) и á, вероятно, будет считаться буквенно-цифровым.

Я отправил такой же вопрос на StackOverflow

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

Представьте себе сеанс отладки: конечно, вы всегда можете вручную написать формулу, которую должен вычислить код, чтобы убедиться, что она верна. Но в девяносто процентов времени вы не будете беспокоиться, и ошибка может оставаться скрытой в течение долгого времени. И никто никогда не захочет смотреть на эту заумную 7-строчную простую формулу ASCII. Конечно, использование юникода не так хорошо, как формула для рендеринга tex, но это намного лучше.

Альтернатива использования длинных описательных имен нежизнеспособна, потому что в математике, если идентификатор не короткий, формула будет выглядеть еще более сложной (как вы думаете, почему люди, примерно в XVIII веке, начали заменять «плюс» на «+» и "минус" на "-"?).

Лично я бы также использовал некоторые индексы и индексы (я просто скопировал и вставил их с этой страницы ). Например: (был разрешен питон √ в качестве идентификатора)

√ = math.sqrt #function alias
c² = c**2
σʷ² = σʷ**2
γ² = γ**2
σ′ʷ = √(σʷ² * (1 - (σʷ²/c²)*Wʷⁱⁿ(t, e)) + γ²)

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

И последнее, я думаю, что этот разговор об использовании не-ASCII символов в первую очередь предвзят, потому что многие программисты никогда не имеют дело с «математически интенсивными формулами записи». Поэтому они думают, что этот вопрос не так важен, потому что они никогда не сталкивались со значительной частью кода, которая потребовала бы использования не-ASCII-идентификаторов. Если вы один из них (а я был до недавнего времени), подумайте об этом: предположим, что буква «а» не является частью ASCII. Тогда у вас будет довольно хорошее представление о проблеме отсутствия греческих букв, индексов и индексов при вычислении нетривиальных математических формул.

Этот код только для вашего личного проекта? Если это так, сходите с ума, используйте все, что вы хотите.

Этот код предназначен для использования другими? т.е. и приложение с открытым исходным кодом какого-то рода? Если это так, вы, скорее всего, просто напрашиваетесь на неприятности, потому что разные программисты используют разные редакторы, и вы не можете быть уверены, что все редакторы будут поддерживать юникод правильно. Кроме того, не все командные оболочки будут отображать его правильно, когда файл исходного кода имеет тип / cat, и вы можете столкнуться с проблемами, если вам нужно отобразить его в формате HTML.

лично я мотивирован рассматривать языки программирования как инструмент для математиков в этом контексте, так как на самом деле я не использую математику, которая выглядит в моей жизни как-то так. : D И конечно, почему бы не использовать ɛ или σ или что-то еще - в этом контексте, это на самом деле более разборчиво.

(Хотя я должен сказать, что я предпочел бы поддерживать числа верхних индексов как прямые вызовы методов, а не имена переменных. Например, 2² = 2 ** 2 = 4 и т. Д.)

Что, черт возьми σ, что W, что ε, cа что γ?
Вы должны назвать свои переменные таким образом, чтобы объяснить, какова их цель.
Я бы лично избил любого, кто оставил бы Unicode или ASCII-версию для меня, чтобы поддерживать, хотя ASCII-версия лучше.

То, что зло зовет переменными σили sили sigmaили valueили var1, потому что это не передает никакой информации.

Предполагая, что вы пишете свой код на английском языке (как я полагаю, вы должны откуда бы вы ни были), ASCII должно быть достаточно, чтобы дать вашим переменным значимые имена, так что в Unicode нет реальной необходимости.

Для имен переменных с известным математическим происхождением это абсолютно приемлемо - даже предпочтительнее. Но если вы когда-нибудь рассчитываете распространить код, вы должны поместить эти значения в модуль, класс и т. Д., Чтобы автозаполнение IDE могло обрабатывать «ввод» странных символов.

Использование √ или ² в идентификаторе - не так уж и много.