Переменные на кирилице?

Question

[Тамаз Харламов]

Здравствуйте.
Обратил внимание что python принимает в коде переменные названные на кириллице и обрабатывает код без ошибок.
Вопрос.
Переменные на кириллице влияют на качество работы кода? Или только на эстетику написания кода есть влияние?

Comments

[Adamos]

Dazhe translit - XPEHOBEHbKO.

[Михаил Р.]

Переменные на кириллице влияют на качество работы кода?

На здоровье влияют...

Answer 1

[Vindicar]

Позволяет. Использовать эту возможность не советую, и в придачу к приведённым выше причинам добавлю ещё одну, очень простую: ключевые слова и вся стандартная библиотека языка на латинице. Задолбаешься переключать раскладку.

Answer 2

[Сергей Водаков]

На работу кода никак не влияет.
А вот путаницы в разработке, особенно в командной, может добавить.

Answer 3

[Сергей Горностаев]

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

Answer 4

[dim5x]

Никак не влияет.
Нравится, удобно - пишите. Особенно, если не планируете что ваш код будут использовать/поддерживать иностранцы.

Comments

[Ziptar]

не планируете что ваш код будут использовать/поддерживать иностранцы.

То есть своих не жалко?

[dim5x]

Нет.
Пошерстите Github, люди пишут так как им удобно: китайцы, индусы, испанцы - и не только комментарии к коду. Лишь русские стесняются, door.close() для них нормально, а дверь.закрыть(), как в примере выше, - ужос-ужос!

[Тамаз Харламов]

dim5x, Коментирую тольок на русском языке. Так как онродной язык и на нем я лучше всего могу донести мысль.

Answer 5

[Everything_is_bad]

Единственное применения этого видел на одном проекте, там был очень специфичная доменная область, и было на много проще называть переменные по русски из этой области, потому что очень часто было общение со специалистами, которые знали только эти названия

Answer 6

[Артём Дайнов]

Мда. лучше так не делать. а то получится. дверь.открыть() дверь.закрыть()

Comments

[pfemidi]

А чем это хуже door.open() и door.close()? IMHO ничем кроме нарушения какого-нибудь корпоративного стандарта написания кода. А если для себя -- "хоть горшком назови, только в печку не ставь".

[Артём Дайнов]

pfemidi, Да я то и не против. Для себя можно хоть как писать. Но если человек привыкнет к такому, потом будет долго въезжать в компаниях, а почему так нельзя.

[Adamos]

pfemidi, когда вам на собеседовании предложат показать код, будет сразу - дверь.закрыть().

[pfemidi]

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

[Adamos]

pfemidi, жизнь - она, с-ка, континиум. Она на "пока что" и "вот потом" - не делится.
В ней "для себя пять лет поговнокодю, а как устроюсь в корпорацию - так сразу возьмусь за стандарт" не бывает. Программирование - навык, он копится от того, что и как делаешь.
Ничего хорошего, кроме дурных привычек, кириллица в программировании не дает. Показывать кому-то такое "написанное для себя" заведомо срамно. Так зачем начинать?

[pfemidi]

Adamos,

Ничего хорошего, кроме дурных привычек, кириллица в программировании не дает

И дружно, и громко скажем это программистам 1С!

Вот только не надо утверждать что те кто пишут для 1С и не программисты вовсе. Не программисты вовсе это которые делают html и css.

[Adamos]

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

[pfemidi]

Adamos, абсолютно согласен. Поэтому я не понимал и не понимаю тех, кто добровольно выбрал html и css и чем их оправдать даже не могу предположить.

[Сергей Водаков]

pfemidi, но позвольте, кто же тогда будет писать html и css?

[pfemidi]

Сергей Водаков, html и css пусть пишет ChatGPT. Ну или те, кто школу прогуливал и кроме как на html и css больше ни на что неспособен.

Answer 7

[Refguser]

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