Чи погано використовувати символи Unicode у назвах змінних? [зачинено]

Нещодавно я намагався реалізувати алгоритм ранжування 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 в ідентифікаторах, так що немає ніякого технічного бар'єру. Або використовувати значущі ідентифікатори. Не замініть грецьких гліфів латинськими гліфами. Або арабські, або хінді.

Особисто мені б не хотілося бачити код, де мені потрібно винести карту символів, щоб знову ввести її. Незважаючи на те, що Unicode тісно відповідає тому, що є в алгоритмі, це дійсно шкодить читанні та здатності редагувати. Деякі редактори можуть навіть не мати шрифту, який підтримує цей символ.

А що з альтернативою і просто мати верх //µ = uі написати все на ascii?

Цей аргумент передбачає, що у вас немає проблем із введенням унікодів та читанням грецьких літер

Ось аргумент: хотіли б ви pi чи circular_ratio?

У цьому випадку я віддаю перевагу pi перед circular_ratio, тому що я дізнався про pi ще з навчання в класі, і можу очікувати, що визначення pi добре вбудоване для всіх програмістів, які вартують його солі. Тому я не був би проти введення π, щоб означати circular_ratio.

Однак про що

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, безумовно, не є тривіальною формулою.

Змінна одинарна літера є прийнятною лише як простий лічильник циклу, будь то грецька однобуквенна або одноциліфрована асції, мені все одно; жодні інші змінні не повинні складатися виключно з однієї літери. Мені байдуже, якщо ви використовуєте грецькі літери для своїх імен, але коли ви їх використовуєте, переконайтесь, що я можу пов’язати ці імена зі «значенням», не потребуючи читати довільний папір деінде.

Коли в школі класу я точно не заперечував би бачити математичні вирази, використовуючи такі символи, як: +, -, ×, ÷, для основної арифметики, а √ () буде функцією квадратного кореня. Після закінчення школи я не заперечую проти додавання нових блискучих символів: ∫ для інтеграції. Зауважте тенденцію, це всі оператори. Оператори набагато сильніше використовуються, ніж імена змінних, але їх рідше використовують для зовсім іншого значення (у випадку, коли математики повторно використовують оператори, нове значення часто все ще має деякі основні властивості старого значення; це не стосується при повторному використанні імен змінних).

На закінчення, ні, не погано використовувати символи Unicode для змінних імен; однак завжди використовувати імена однієї літери для змінних імен завжди погано, а дозволяти використовувати імена Unicode - це не ліцензія на використання одноіменних імен змінних.

Ви розумієте код? Чи всі інші, кому це потрібно читати? Якщо так, то проблем немає.

Особисто я радий побачити задню частину вихідного коду лише для ASCII.

Так, ви поза розумом. Я б особисто посилався на номер паперу та формули в коментарі, і писав би все прямо ASCII. Тоді кожен бажаючий зможе співвіднести код і формулу.

Я б сказав, що використання імен змінних Unicode є поганою ідеєю з двох причин:

1. Вони набирають ПДФА.

2. Вони часто виглядають майже так само, як англійські букви. Це та сама причина, чому я ненавиджу бачити грецькі букви в математичній нотації. Спробуйте сказати rho крім p. Це не легко.

У цьому випадку складна математична формула, я б сказав, підемо на це.

Я можу сказати, що за 20 років мені ніколи не доводилося кодувати щось таке складне, а грецькі букви тримають це близько до оригінальної математики. Якщо ви не можете зрозуміти це, ви не повинні підтримувати його.

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

• Про: це виглядає приємно
• Con: символи unicode, і тому все значення може загубитися в ланцюзі інструментів (редактор, формат-код коду, контроль версій, старший компілятор)

Наскільки великий для вас ризик? Чи виграє переваги від ризику?

Колись у не надто віддаленому майбутньому всі ми будемо використовувати текстові редактори / IDE / веб-браузери, які полегшують запис редагування тексту, включаючи класичні грецькі символи тощо. (А може, ми всі навчилися використовувати це "приховане" "функціональність в інструментах, якими ми зараз користуємося ...)

Але поки це не станеться, не ASCII символи у вихідному коді програми багатьом програмістам важко впораються, і тому погана ідея, якщо ви пишете програми, які, можливо, потребуватимуть підтримувати хтось інший.

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

Ви не сказали, якою мовою / компілятором користуєтесь, але зазвичай правило для імен змінних полягає в тому, що вони повинні починатись з алфавітного символу або підкреслення і містити лише буквено-цифрові знаки та підкреслення. Unicode √ не вважатиметься буквено-цифровим, оскільки він є математичним символом замість літери. Однак σ може бути (оскільки він є грецьким алфавітом), і, ймовірно, вважатиметься буквено-цифровим.

Я розмістив такий же запит на StackOverflow

Я, безумовно, вважаю, що варто використовувати unicode у важких математичних проблемах, оскільки це дає змогу читати формулу безпосередньо, що неможливо із звичайним ASCII.

Уявіть собі сесію налагодження: звичайно, ви завжди можете вручну написати формулу, яку слід обчислити, щоб перевірити, чи правильна вона. Але дев'яносто відсотків часу ви не будете турбуватися, і помилка може залишатися прихованою довгий довгий час. І ніхто ніколи не бажає дивитися на цю необґрунтовану 7-лінійну просту формулу ASCII. Звичайно, використання Unicode не так добре, як текстово-візуалізована формула, але це набагато краще.

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

Особисто я також би використовував деякі підписки та надписи (я просто копіюю та вставляю їх із цієї сторінки ). Наприклад: (мав дозволений пітон √ як ідентифікатор)

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

Де я використав суперскрипти, тому що в unicode немає еквівалентного індексу. (На жаль, набір символів підпису unicode дуже обмежений. Я сподіваюся, що одного дня підписка на unicode буде вважатися діакритикою, тобто комбінацією одного знака для підписки та іншого char для підписаного листа)

І останнє, я вважаю, що ця розмова про використання символів, що не належать до ASCII, є в основному упередженою, тому що багато програмістів ніколи не мають справу з "формулами, інтенсивними математичними позначеннями". Тому вони вважають, що це питання не так важливо, оскільки вони ніколи не відчували значної частини коду, яка вимагала б використання ідентифікаторів, що не належать до ASCII. Якщо ви один із них (а я був до недавнього часу), врахуйте це: припустимо, що літера "а" не є частиною ASCII. Тоді ви будете мати досить гарне уявлення про проблему, коли під час обчислення нетривіальних математичних формул немає грецьких букв, підписок, надписів.

Це код лише для вашого особистого проекту? Якщо так, горіхи, використовуйте все, що завгодно.

Чи призначений цей код для використання іншими? тобто, програма з відкритим кодом якогось типу? Якщо це так, ви, ймовірно, просто задаєте проблеми, оскільки різні програмісти використовують різні редактори, і ви не можете бути впевнені, що всі редактори будуть правильно підтримувати unicode. Крім того, не всі командні оболонки показують його правильно, коли файл вихідного коду вводиться type'd / cat'd, і ви можете зіткнутися з проблемами, якщо вам потрібно відобразити його в html.

особисто я мотивований розглядати мови програмування як інструмент для математиків у цьому контексті, оскільки я фактично не використовую математику, яка виглядає у житті нічого подібного. : D І звичайно, чому б не використати ɛ або σ чи що завгодно - у цьому контексті це насправді більш розбірливо.

(Хоча, я мушу сказати, моїм перевагою було б підтримувати надпрограмні номери як прямі виклики методів, а не імена змінних. Наприклад, 2² = 2 ** 2 = 4 і т.д.)

Що, чорт візьми σ, що W, що ε, cа що γ?
Ви маєте назвати свої змінні таким чином, щоб пояснити, яка їх мета.
Я особисто бив усіх, хто покинув Unicode або ASCII-версію, щоб я їх підтримував, хоча версія ASCII краще.

Що таке зло, викликає змінні σабо sабо sigmaабо valueабо var1, оскільки це не передає жодної інформації.

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

Для імен змінних з добре відомим математичним походженням це абсолютно прийнятно - навіть бажано. Але якщо ви коли-небудь розраховуєте поширити код, вам слід розмістити ці значення в модулі, класі тощо, щоб автоматичне завершення IDE могло впоратися з "набором" дивних символів.

Використання √ або ² в ідентифікаторі - не так вже й багато.