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




имена переменных в python (8)

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

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

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


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

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

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

  • StudlyCaps для классов

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


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

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

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

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

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


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

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


См. Python PEP 8 .

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

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

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

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

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


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


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

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


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

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

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

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

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

Рекомендации, взятые из рекомендаций Гвидо





naming-conventions