Какое соглашение об именах в 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?

15 ответов

Решение

Смотрите Python PEP 8.

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

mixedCase допускается только в тех случаях, когда это уже преобладающий стиль

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

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

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

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

имя_модуля, имя_пакета, имя_класса, имя_процесса, имя_исключения, имя_функции, GLOBAL_CONSTANT_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", во всяком случае, пока.

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

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

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

Далее на что @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 лет, но я до сих пор не люблю их. Они просто выглядят мне некрасиво, но, возможно, это все, что связано с Явой в моей голове.

Мне просто больше нравится 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. Вот почему современные языки используют (или должны использовать) змею везде, где могут.

Будь то в классе или вне класса:

Переменная и функция написаны строчными буквами , как показано ниже:

      name = "John"
      def display(name):
    print("John")

А если это более одного слова, они разделяются символом подчеркивания «_» , как показано ниже:

      first_name = "John"
      def display_first_name(first_name):
    print(first_name)

И, если переменная является константой, она пишется в верхнем регистре , как показано ниже:

      FIRST_NAME = "John"

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

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

Ленин сказал ... Я тоже из мира Java/C#. И SQL тоже. Присматривался к себе в попытках найти на первый взгляд понятные примеры сложных конструкций типа списка в словаре списков, где все является объектом. На мой взгляд, camelCase или их варианты должны стать стандартом для любого языка. Подчеркивания следует сохранять для сложных предложений.

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

Другие вопросы по тегам