Какое соглашение об именах в Python для имен переменных и функций?

Question

Исходя из фона C #, соглашение о присвоении имен для переменных и имен методов обычно бывает CamelCase или Pascal Case:

// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()

В Python я видел вышеупомянутое, но я также видел используемые подчеркивания:

# python example
this_is_my_variable = 'a'
def this_is_my_function():

Есть ли более предпочтительный, определенный стиль кодирования для Python?

Answer 1

См. Python PEP 8 .

Имена функций должны быть строчными, со словами, разделенными подчеркиванием как необходимо улучшить читаемость.

mixedCase разрешено только в контекстах где это уже преобладает стиль

Переменные ...

Используйте правила именования функций: строчные со словами, разделенными подчеркивает по мере необходимости, чтобы улучшить читаемость.

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

Answer 2

Руководство по стилю Google Python имеет следующее соглашение:

имя модуля, имя пакета, имя класса, имя метода, имя исключения, имя_функции, GLOBAL_CONSTANT_NAME, глобальное_ва_имя, имя_экземпляра_параметра, имя_функции_параметра, имя_квартира_100 *

Аналогичная схема именования должна применяться к CLASS_CONSTANT_NAME

Answer 3

Дэвид Гуджер (в «Коде как Pythonista» здесь ) описывает рекомендации PEP 8 следующим образом:

• joined_lower для функций, методов, атрибуты, переменные

• joined_lower или ALL_CAPS для Константы

• StudlyCaps для занятий

• camelCase только для соответствия ранее существовавшие соглашения

Answer 4

Как признается Руководство по стилю для кода Python ,

Соглашения об именах в Python библиотека немного беспорядок, поэтому мы будем никогда не получайте это полностью последовательным

Обратите внимание, что это относится только к стандартной библиотеке Python . Если они не могут согласовать , то вряд ли можно надеяться на наличие общепринятого соглашения для всего кода Python, так?

Из этого и из обсуждения здесь я бы сделал вывод, что это не ужасный грех, если человек продолжает использовать, например. Соглашения об именах переменных и функций в Java или C # (понятные и хорошо разработанные) при переходе на Python. Имея в виду, конечно, что лучше всего придерживаться того стиля, который преобладает для базы кода / проекта / команды. Как указывает руководство по стилю Python, внутренняя согласованность важнее всего.

^{Не стесняйтесь уволить меня как еретика. :-) Как и OP, я не "Pythonista", пока что нет.}

Answer 5

Существует PEP 8 , как показывают другие ответы, но PEP 8 - это только руководство по стилю для стандартной библиотеки, и оно воспринимается только как Евангелие. Одним из наиболее частых отклонений PEP 8 для других частей кода является именование переменных, особенно для методов. Единого преобладающего стиля не существует, хотя, учитывая объем кода, который использует mixedCase, если провести строгую перепись, возможно, получится версия PEP 8 с mixedCase. Есть небольшое другое отклонение от PEP 8, которое столь же распространено.

Answer 6

Как уже упоминалось, PEP 8 говорит использовать lower_case_with_underscores для переменных, методов и функций.

Я предпочитаю использовать lower_case_with_underscores для переменных и mixedCase для методов и функций, чтобы сделать код более явным и читабельным. Таким образом, после Zen of Python «явное лучше, чем неявное» и «Читаемость рассчитывает»

Answer 7

Лично я стараюсь использовать CamelCase для классов, методов и функций mixedCase. Переменные обычно разделяются подчеркиванием (когда я могу вспомнить). Таким образом, я сразу вижу, что именно я звоню, а не все выглядит одинаково.

Answer 8

Большинство людей, предпочитающих python, предпочитают подчеркивание, но даже я использую python уже более 5 лет, но я до сих пор не люблю их. Они просто выглядят мне некрасиво, но, возможно, это все, что связано с Java в моей голове.

Мне просто больше нравится CamelCase, поскольку он лучше подходит для именования классов. Логичнее иметь SomeClass.doSomething(), чем SomeClass.do_something(). Если вы посмотрите в глобальном модульном индексе в python, вы найдете и то, и другое, что связано с тем, что это коллекция библиотек из разных источников, которые со временем выросли, а не что-то, разработанное одной компанией, такой как Sun, со строгими правилами кодирования. , Я бы сказал, что суть в том, что лучше использовать то, что вам больше нравится, это просто вопрос личного вкуса.

Answer 9

дальше того, на что ответил @JohnTESlade. Руководство по стилю Google Python содержит несколько довольно аккуратных рекомендаций,

Имена, которых следует избегать

• имена из одного символа, за исключением счетчиков или итераторов
• тире (-) в любом имени пакета / модуля
• \__double_leading_and_trailing_underscore__ names (зарезервировано Python)

Соглашение о присвоении имен

• «Внутренний» означает внутренний для модуля или защищенный или частный в классе.
• Добавление одного подчеркивания (_) имеет некоторую поддержку для защиты переменных и функций модуля (не входит в импорт * из). Добавление двойного подчеркивания (__) к переменной или методу экземпляра эффективно делает переменную или метод приватными для своего класса (используя искажение имени).
• Поместите связанные классы и функции верхнего уровня вместе в модуль. В отличие от Java, нет необходимости ограничивать себя одним классом на модуль.
• Используйте CapWords для имен классов, но lower_with_under.py для имен модулей. Хотя существует много существующих модулей с именем CapWords.py, сейчас это не рекомендуется, потому что сбивает с толку, когда модуль назван в честь класса. («подождите - я написал import StringIO или from StringIO import StringIO?»)

Руководства, основанные на рекомендациях Гвидо

Answer 10

Есть бумага по этому поводу: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR. Это говорит о том, что snake_case более читабелен, чем camelCase. Вот почему современные языки используют (или должны использовать) змею везде, где могут.