Каково соглашение об именах в Python для имен переменных и функций?
Исходя из фона 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?
Ответы 13
См. Python PEP 8: Имена функций и переменных:
Function names should be lowercase, with words separated by underscores as necessary to improve readability.
Variable names follow the same convention as function names.
mixedCase is allowed only in contexts where that's already the prevailing style (e.g. threading.py), to retain backwards compatibility.
Как насчет имен аргументов функций (в частности, для аргументов ключевых слов)? PEP 8 не говорит о них однозначно. Для них я тоже использую строчные буквы с подчеркиванием. Или предпочтительнее использовать нижний регистр без подчеркивания?
Единственная проблема с использованием подчеркивания заключается в том, что вы не можете выбрать имя переменной или функции двойным щелчком ... вам нужно выбрать текст вручную. Это немного раздражает.
@RickyRobinson Какой умный редактор кода вы используете, который не знает, что подчеркивание продолжает слово? Множество бесплатных, которые подходят. Я использую Notepad ++, если IDE недоступна. Для этого можно скачать шаблон для редактирования Python. (Другие могут порекомендовать еще более полезные бесплатные загрузки.)
Я собрал команду sed для преобразования mixedCase (но не CapitalWords) в lower_case_with_underscores на случай, если кто-то сочтет это полезным, например чтобы сделать это так, как вам нравится, но затем отпустите его предпочтительным способом PEP 8: stackoverflow.com/questions/23607374
Одним из примеров использования подчеркнутого стиля является то, что вы можете лучше использовать однобуквенные слова. Для (довольно глупого) примера findMeAClass, возможно, уродливее find_me_a_class.
Я считаю, что соглашение об именах переменных в нижнем регистре не подходит для научных вычислений, где часто встречаются хорошо известные константы, тензоры и т. д., Которые обозначаются заглавными буквами.
обратите внимание, что в руководстве сказано «по мере необходимости для улучшения читабельности». Таким образом, вы также можете просто объединить без подчеркивания, если это выглядит лучше. Итак: lower_case_with_underscores, также может быть, lowercase_with_underscores и utc_from_timestamp может быть utcfromtimestamp
Стандарты существуют, чтобы следовать им, а не подвергать их сомнению. Я не отношусь к людям, которые говорят, что «этот стандарт - отстой. Я сделаю свой собственный стандарт», очень высоко. При этом правило: mixedCase is allowed only in contexts where that's already the prevailing style делает все это правило совершенно бессмысленным. Какой стандарт говорит вам «делать X ... если вы этого не сделаете» ...?
@rr PEP8 - это «Руководство по стилю», которое описывает себя как конвенцию, а не как стандарт. Это также ясно объясняет причины не всегда соблюдения этих «правил».
@andreasdr С одной стороны, вы правы, но с другой стороны, в каждом соглашении об именах заложена идея «стандартного» соглашения о регистре. Итак, в camelCase вы должны использовать заглавную букву «e» для числа Эйлера. На этом этапе вы можете возразить, что он больше не действует как алфавитный символ, а вместо этого ведет себя как собственный символ. Кстати, именно поэтому такие символы обычно выделяются курсивом или иным образом смещаются (например, курсив L для преобразования Лапласа).
Это может быть немного не по теме, потому что меня беспокоит соглашение об именах для классов, НО: когда люди говорят, что соглашение о стиле для классов - UpperCase, означает ли это, что это верно только для определений, но также и для экземпляров классов?
Я не вижу пользы от следования PEP 8, в то время как Javascript, php, swift, java и другие языки в основном используют camelCase для метода. Вы не должны менять свой стиль кодирования для каждого языка, это глупо. В общем, CamelCase - лучший выбор whathecode.wordpress.com/2011/02/10/…
Не так быстро, @TomSawyer! В статье, на которую есть ссылка в блоге, было обнаружено, что верблюжий футляр дает большую точность, но поиск «идентификаторов, написанных в стиле верблюжьего футляра, занимает на 0,42 секунды больше времени». Но тренировки в верблюжьем кейсе действительно делают нас быстрее в этом стиле. (См. Стр. 7-8 в <PDF>. Таким образом, случай верблюда медленнее в целом, но безопаснее, когда есть похожие переменные - и это была очень узкая экспериментальная установка, как указывают авторы.
@alexis Я ничего не сказал о том, какой из них быстрее печатает. Все, что я хотел сказать, это то, что менять стиль кодирования для каждого языка - глупая вещь. CamelCase - это везде, особенно в эпоху Json. google.github.io/styleguide/jsoncstyleguide.xml
На самом деле речь шла не о наборе текста, а о выявлении идентификаторов среди других слов. Но вы правы, стили изменение обходятся дорого, независимо от того, в каком направлении вы идете.
Зачем игнорировать продолжение? whathecode.wordpress.com/2013/02/16/… Итак, первое исследование показало, что чтение случая с верблюдами занимает на 13,5% больше времени, в то время как второе исследование показало, что это занимает на 20% больше времени. Дело верблюда следует переименовать в "дело улитки"!
Стоит отметить, что из того же документа в разделе «Глупая последовательность - хобгоблин маленьких умов»: «Однако знайте, когда следует проявлять непоследовательность - иногда рекомендации руководства по стилю просто не применимы. Если вы сомневаетесь, используйте все возможное суждение. Посмотрите на другие примеры и решите, что выглядит лучше всего. И не стесняйтесь спрашивать! "
@Yablargo переключитесь на Dvorak, и вы обнаружите, что lower_case_names намного быстрее набирать, поскольку клавиша подчеркивания «_» находится в главном ряду клавиатуры.
Что вы порекомендуете, если вам нужна переменная, которая является зарезервированным ключевым словом, например type? typee ttype тип тип
@ thanos.a Используйте type_, если он уже зарезервирован. _type предназначен для имен защищенных переменных.
MixedCase теперь довольно стандартен, подчеркивание занимает слишком много места
Стиль кодирования обычно является частью внутренней политики / стандартов организации, но я думаю, что в целом стиль all_lower_case_underscore_separator (также называемый snake_case) наиболее распространен в Python.
Как показывают другие ответы, существует PEP 8, но PEP 8 является только руководством по стилю для стандартной библиотеки, и в нем он воспринимается только как евангелие. Одним из наиболее частых отклонений от PEP 8 для других частей кода является именование переменных, особенно для методов. Не существует единого преобладающего стиля, хотя, учитывая объем кода, в котором используется mixedCase, при проведении строгой переписи, вероятно, получится версия PEP 8 со смешаннымCase. Есть небольшое другое отклонение от PEP 8, которое столь же распространено.
Возможно, это было правдой в '08, когда на этот вопрос был дан ответ, но в настоящее время почти все основные библиотеки используют соглашения об именах PEP 8.
Большинство питоновцев предпочитают символы подчеркивания, но даже если я использую Python уже более 5 лет прямо сейчас, они мне все равно не нравятся. Мне они кажутся некрасивыми, но, может быть, это вся ява в моей голове.
Мне просто больше нравится CamelCase, так как он лучше соответствует способу именования классов. Кажется, более логичным иметь SomeClass.doSomething(), чем SomeClass.do_something(). Если вы посмотрите в глобальном индексе модулей в python, вы найдете и то, и другое, что связано с тем, что это коллекция библиотек из разных источников, которые росли сверхурочно, а не что-то, что было разработано одной компанией, такой как Sun, со строгими правилами кодирования. . Я бы сказал, что суть в следующем: используйте то, что вам больше нравится, это просто вопрос личного вкуса.
У меня опыт работы с Java, и я считаю подчеркивание многословным и непривлекательным, и только последнее является мнением. Именование - это в некотором смысле баланс между удобочитаемостью и краткостью. Unix заходит слишком далеко, но его en.wikipedia.org/wiki/Domain-specific_language ограничен. CamelCase читается благодаря заглавным буквам, но без лишних символов. 2c
Для меня подчеркивания привлекательны в функциях / методах, поскольку я вижу каждое подчеркивание как разделитель для виртуального (в моей голове) пространства имен. Таким образом, я могу легко узнать, как назвать свои новые функции / методы: make_xpath_predicate, make_xpath_expr, make_html_header, make_html_footer.
Вы (обычно) не вызываете SomeClass.doSomething() (статические методы обычно редки), вы обычно вызываете an_instance.do_something()
Лично я стараюсь использовать CamelCase для классов, методов и функций mixedCase. Переменные обычно разделяются подчеркиванием (насколько я помню). Таким образом, я могу с первого взгляда сказать, что именно я звоню, вместо того, чтобы все выглядело одинаково.
Регистр Camel начинается со строчной буквы IIRC, например «camelCase».
Я думаю, что crystalattice был прав - по крайней мере, его использование согласуется с использованием в PEP8 (CamelCase и mixedCase).
@UnkwnTech Термин для FirstLetterUpper иногда называют PascalCase
CamelCase или camelCase? просто интересуюсь.
Дэвид Гуджер (в «Коде как Pythonista» здесь) описывает рекомендации PEP 8 следующим образом:
joined_lowerдля функций, методов, атрибуты, переменныеjoined_lowerилиALL_CAPSдля константыStudlyCapsдля занятийcamelCaseтолько для соответствия ранее существовавшие конвенции
+1 наглядные примеры. Хотя я не мог видеть, где PEP8 предлагает joined_lower для константы, только «все заглавные буквы с подчеркиванием, разделяющими слова». Также интересно узнать о новой функции перечислить.
StudlyCaps for classes - отличное универсальное правило для занятий практически со всеми языками. Тогда почему некоторые встроенные классы Python (например, datetime.datetime не соответствуют этому соглашению?
@PrahladYeri: К сожалению, unittest.TestCase.assertEqual и его друзья также не следуют соглашению snake_case. Правда в том, что части стандартной библиотеки Python были разработаны до того, как соглашения закрепились, и теперь мы придерживаемся их.
CamelCase сбивает с толку, потому что некоторые люди говорят, что это «camelCase» (также известный как «mixedCase»), а некоторые люди говорят, что это «CamelCase» (также известный как «StudlyCaps»). Например, PEP упоминает «CamelCase», а вы упоминаете «camelCase».
ваша вот-ссылка мертва, может ее стоит заменить на что-то вроде david.goodger.org/projects/pycon/2007/idiomatic
Как правило, следуют соглашениям, используемым в стандартной библиотеке языка.
Как уже упоминалось, в PEP 8 говорится об использовании lower_case_with_underscores для переменных, методов и функций.
Я предпочитаю использовать lower_case_with_underscores для переменных и mixedCase для методов и функций, что делает код более понятным и читаемым. Таким образом, следуя Дзен Питона «явное лучше, чем неявное» и «удобочитаемость имеет значение»
+1 Я переключаю эти два (я использую MixCase для переменных), но наличие всего такого более отчетливого помогает сразу понять, с чем вы имеете дело, тем более что вы можете передавать функции.
Хотя "читабельность" очень субъективна. Я считаю, что методы с подчеркиванием более читабельны.
Ваше предпочтение было моей первоначальной интуицией, появившейся после многих лет разработки Java. Мне нравится использовать _ для переменных, но мне кажется, что функции и методы кажутся мне немного забавными.
Как признает Руководство по стилю кода Python,
The naming conventions of Python's library are a bit of a mess, so we'll never get this completely consistent
Обратите внимание, что это относится только к Python стандартная библиотека. Если они не могут добиться согласованности который, то вряд ли есть большая надежда на то, чтобы иметь общее соглашение для кода все Python, не так ли?
Из этого и из обсуждения здесь я бы сделал вывод, что нет - ужасный грех, если кто-то продолжает использовать, например, Соглашения Java или C# (ясные и хорошо зарекомендовавшие себя) об именах для переменных и функций при переходе на Python. Помня, конечно, что лучше всего придерживаться того стиля, который преобладает в кодовой базе / проекте / команде. Как указано в Руководстве по стилю Python, Внутренняя согласованность имеет наибольшее значение.
Feel free to dismiss me as a heretic. :-) Like the OP, I'm not a "Pythonista", not yet anyway.
Руководство по стилю 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.
а) Обожаю примеры - спасибо. б) Неприятная смесь CamelCase и подчеркивания? Но: будучи новичком в Python и его более гибкой модели данных, держу пари, что руководство Google основано на серьезных размышлениях ...
Смешивание @MatthewCornell неплохо, если вы его придерживаетесь. На самом деле это облегчает чтение, если вы знаете, что у функций есть символы подчеркивания, а у классов нет.
@MatthewCornell Я бы не подумал, что это как-то связано с питоном. Go фактически применяет произвольные стандарты красоты и не сможет скомпилировать, если вы, например, не будете придерживаться их соглашения о фигурных скобках. По сути, это игра в кости, чтобы выяснить, действительно ли кто-то серьезно подумал или ему просто очень понравилось то, как он что-то делает.
Считаете ли вы постоянный статический атрибут GLOBAL_CONSTANT_NAME? Это не совсем глобально, поскольку находится в области действия класса.
затем переходит к property ... возможно, дело в том, за что претендует элемент, а не в том, что он на самом деле
Я не знаю, должен ли это быть отдельным вопросом, но одно соглашение, не упомянутое здесь, заключается в том, как назвать аргументы функции. Я думаю, что это вписывается в рамки этого вопроса, поэтому было бы неплохо, если бы на него также был дан ответ здесь. Например, если что-то требует общих списков, какими должны быть. Я думаю, что не рекомендуется использовать, например, list или dict в качестве имени аргумента функции, поскольку они уже существуют. Что следует использовать вместо этого? LS, DC?
Об этом есть статья: 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)
Соглашение об именовании
- «Внутренний» означает внутренний по отношению к модулю или защищенный или частный внутри класса.
- Добавление одиночного подчеркивания (_) имеет некоторую поддержку для защиты переменных и функций модуля (не входит в импорт * из). Добавление двойного подчеркивания (__) к переменной или методу экземпляра эффективно служит для того, чтобы сделать переменную или метод закрытым для своего класса (с использованием изменения имени).
- Поместите связанные классы и функции верхнего уровня вместе в модуль. В отличие от Java, нет необходимости ограничивать себя одним классом на модуль.
- Используйте
CapWordsдля имен классов, ноlower_with_under.pyдля имен модулей. Хотя существует много существующих модулей с именемCapWords.py, сейчас это не рекомендуется, потому что это сбивает с толку, когда модуль назвали в честь класса. ("подождите - я писалimport StringIOилиfrom StringIO import StringIO?")
Я лично использую соглашения об именах Java при разработке на других языках программирования, поскольку они последовательны и просты в использовании. Таким образом, я не буду постоянно бороться за то, какие соглашения использовать, что не должно быть самой сложной частью моего проекта!
Я частично согласен. Если язык X - это лишь небольшая часть проекта, переключение контекста того, как форматировать текст, может стать обузой. Основная проблема в том, что библиотеки будут иметь вызовы в одном стиле (library_function(my_arg)).
PEP = Предложение по усовершенствованию Python.