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


774

Исходя из фона 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?

Ответы:


868

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

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

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

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


127
PEP = Предложение по улучшению Python.
Питер Мортенсен

8
@RickyRobinson Какой редактор кода вы используете, который не знает, что подчеркивание продолжает слово? Много бесплатных, которые делают. Я использую Notepad ++, если IDE недоступна. Для этого можете скачать шаблон для редактирования на питоне. (Другие могут порекомендовать еще больше полезных бесплатных загрузок.)
ToolmakerSteve

57
Одним из примеров подчеркнутого стиля является то, что вы можете лучше использовать однобуквенные слова. Для (довольно глупый) пример, findMeAClassвозможно, более уродлив, чем find_me_a_class.
heltonbiker

9
Я нахожу, что соглашение имен строчных букв всех строчных букв не подходит для научных вычислений, где часто встречаются общеизвестные константы, тензоры и т. Д., Которые обозначаются заглавными буквами.
andreasdr

12
@rr PEP8 - это «Руководство по стилю», которое описывает себя как конвенцию, а не как стандарт. Это также ясно объясняет причины не всегда следования этим «правилам».
Тахаан

710

Руководство по стилю 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


37
а) я люблю примеры - спасибо. б) Непривлекательная смесь CamelCase и подчеркивания? Но: будучи новичком в Python и его более гибкой модели данных, я уверен, что за руководством Google стоит серьезная мысль ...
Мэтью Корнелл,

19
@MatthewCornell смешивание не плохо, если вы придерживаетесь его. На самом деле это делает читабельность проще, если вы знаете, что у функций есть подчеркивания, а у классов нет.
Питикос

1
@ MatthewCornell Я бы не подумал, что это как-то связано с питоном. Go фактически применяет произвольные стандарты красоты и не сможет скомпилироваться, если вы не будете придерживаться, например, их соглашения о фигурных скобках. По сути, это бросок костей в отношении того, задумывался ли кто-то на самом деле о тщательной мысли или просто действительно любил то, как они делают вещи.
Парфянский выстрел

Считаете ли вы постоянный статический атрибут GLOBAL_CONSTANT_NAME? Это не совсем глобально, так как это входит в сферу деятельности класса.
Джеймс Т.

затем входит property... возможно, дело в том, какой предмет притворяется, а не в том, чем он является на самом деле
joelb

240

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

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

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

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

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


3
+1 наглядные примеры. Хотя я не мог видеть , где PEP8 предлагает joined_lowerдля постоянных , только «всех заглавных букв подчеркивания отделяя слова». Любопытно также о новой функции enum .
Боб Стейн

1
StudlyCaps for classesотличное универсальное правило для занятий практически на всех языках. Тогда почему некоторые встроенные в Python классы (например datetime.datetime, не соблюдающие это соглашение?
Прахлад Ери

3
@PrahladYeri: К сожалению, unittest.TestCase.assertEqualи друзья тоже не соблюдают соглашение snake_case. Правда состоит в том, что части стандартной библиотеки Python были разработаны до того, как соглашения укрепились, и теперь мы застряли с ними.
wchargin

3
CamelCase сбивает с толку, потому что некоторые люди говорят, что это «camelCase» (также известный как «mixedCase»), а некоторые люди говорят, что это «CamelCase» (также известный как «StudlyCaps»). Например, PEP упоминает «CamelCase», а вы упоминаете «CamelCase».
Pro Q

Ваша ссылка здесь мертва, возможно, ее следует заменить чем-то вроде david.goodger.org/projects/pycon/2007/idiomatic
Wolf

42

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

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

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

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

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


32

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


9
Возможно, это было правдой в 2008 году, когда на этот вопрос был дан ответ, но в настоящее время почти все основные библиотеки используют соглашения об именах PEP 8.
Тейн Бримхолл

29

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

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


3
+1 Я переключаю эти два (я использую mixedCase для переменных), но наличие всего более отчетливого помогает сразу понять, с чем вы имеете дело, тем более что вы можете передавать функции.
Xiong Chiamiov

2
Хотя «Читаемость» очень субъективна. Я считаю методы с подчеркиванием более читабельными.
Питикос

Ваше предпочтение было моей первоначальной интуицией, пришедшей из многих лет разработки Java. Мне нравится использовать _ для переменных, но на первый взгляд для функций и методов это выглядит немного забавно.
Михаил Щепаняк,

21

далее на что @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?»)

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


17

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

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


10
Я пришел из Java, и я нахожу подчеркивание многословным и непривлекательным, и только последнее является мнением. Именование в некотором отношении является балансом между удобочитаемостью и краткостью. Unix заходит слишком далеко, но его en.wikipedia.org/wiki/Domain-specific_language ограничен. CamelCase читается благодаря колпачкам, но не имеет дополнительных символов. 2c
Мэтью Корнелл,

2
Для меня подчеркивания привлекательны в функциях / методах, так как я вижу каждое подчеркивание как разделитель для виртуального (в моей голове) пространства имен. Таким образом , я могу легко узнать , как назвать мои новые функции / методы: make_xpath_predicate, make_xpath_expr, make_html_header,make_html_footer
Pithikos

3
Вы (обычно) не вызываете SomeClass.doSomething()(статические методы обычно редки), вы обычно вызываетеan_instance.do_something()
Дейв

15

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


15
Случай с верблюдом начинается со строчной буквы IIRC, например, «camelCase».
UnkwnTech

11
Я думаю, что у Crystalattice это было правильно - по крайней мере, его использование соответствует использованию в PEP8 (CamelCase и mixedCase).
Джаррет

1
@UnkwnTech Термин для FirstLetterUpper иногда называется PascalCase
SurpriseDog

CamelCase или CamelCase? просто интересуюсь.
Сумит Похрел

11

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

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


9
Интересно, что в нем также говорится: «Результаты этого исследования могут не обязательно применяться к идентификаторам, встроенным в исходный код. Вполне возможно, что идентификаторы на верблюдах могут выступать в качестве лучшего элемента гештальта при внедрении в программные конструкции».
rob3c

2

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


0

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


Я несколько согласен. Если язык X представляет собой лишь небольшую часть проекта, переключение контекста форматирования текста может быть бременем. Основной недостаток заключается в том, что библиотеки будут иметь вызовы в одном стиле ( library_function(my_arg)).
Лан

-2

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.