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

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

12 ответов


См. Python PEP 8.

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

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

переменные...

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

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


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

module_name, package_name, ClassName, method_name, ExceptionName, имя_функции, GLOBAL_CONSTANT_NAME, global_var_name, instance_var_name, function_parameter_name, local_var_name

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


Дэвид Гуджер (в "код как Pythonista" здесь) описывает рекомендации ОПТОСОЗ 8 следующим образом:

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

  • joined_lower или ALL_CAPS для константы!--8-->

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

  • camelCase только соответствовать существующих конвенций


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

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

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

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

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


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


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

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


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


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

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


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

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


далее @JohnTESlade ответил. руководство Google по стилю python имеет некоторые довольно интересные рекомендации,

имена, чтобы избежать

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

Соглашение Об Именах

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

рекомендации, полученные из рекомендаций Гвидо enter image description here


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


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