Что такое соглашение об именах в 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
?")
стиль кодирования обычно является частью стандартов внутренней политики/соглашения организации, но я думаю, что в целом стиль all_lower_case_underscore_separator (также называемый snake_case) наиболее распространен в python.