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

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

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

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

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

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

Смотрите Python PEP 8: имена функций и переменных :

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

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

mixedCase допускается только в тех случаях, когда это уже преобладающий стиль (например, threading.py ), чтобы сохранить обратную совместимость.

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

module_name, package_name, ClassName, method_name, ExceptionName, function_name, GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name,function_parameter_name , local_var_name.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соглашение об именовании

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

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

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

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

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

Об этом есть статья: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

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

Стиль кодирования обычно является частью внутренних стандартов политики / конвенции организации, но в целом, я думаю, что стиль all_lower_case_underscore_separator (также называемый snake_case) наиболее распространен в python.

Я лично использую соглашения об именах в Java при разработке на других языках программирования, так как они последовательны и просты в использовании. Таким образом, я не буду постоянно спорить о том, какие соглашения использовать, которые не должны быть самой сложной частью моего проекта!

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