Исходя из фона С#, соглашения о присвоении имен для переменных и имен методов обычно бывают camelCase или PascalCase:
// C# example
string thisIsMyVariable = "a"
public void ThisIsMyMethod()
В Python я видел вышеупомянутое, но я также видел подчеркивание:
# python example
this_is_my_variable = 'a'
def this_is_my_function():
Есть ли более предпочтительный, определенный стиль кодирования для Python?
См. Python PEP 8.
Названия функций должны быть строчными, со словами, разделенными символами подчеркивания, как для улучшения удобочитаемости.
mixedCase допускается только в контекстах где это уже преобладает стиль
Переменные...
Используйте правила именования функций: нижний регистр со словами, разделенными подчеркивает, что необходимо улучшить читаемость.
Лично я отклоняюсь от этого, потому что я также предпочитаю mixedCase над lower_case для своих собственных проектов.
Руководство по стилю 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
Дэвид Гудгер (в "Code Like a Pythonista" здесь) описывает рекомендации PEP 8 следующим образом:
joined_lower для функций, методов,
атрибуты, переменные
joined_lower или ALL_CAPS для
Константы
StudlyCaps для классов
camelCase только для соответствия
ранее существовавшие соглашения
Как Руководство по стилю для кода Python допускает,
Соглашения об именах Python библиотека немного беспорядочна, поэтому мы будем никогда не получите это полностью согласованное
Обратите внимание, что это относится только к стандартной библиотеке Python. Если они не могут получить это согласованно, то вряд ли есть большая надежда иметь общепринятое соглашение для всего кода Python, есть ли?
Из этого и обсуждения здесь я бы сделал вывод, что не ужасный грех, если продолжать использовать, например. Java или С# (четкие и хорошо установленные) соглашения об именах для переменных и функций при переходе на Python. Имея в виду, конечно, что лучше всего придерживаться любого преобладающего стиля для кодовой базы/проекта/команды. Как указывает руководство по стилю Python, важна внутренняя согласованность.
Не стесняйтесь увольнять меня как еретика.:-) Как и OP, я не являюсь "Pythonista", еще не все равно.
Существует PEP 8, как показывают другие ответы, но PEP 8 является только стилем для стандартной библиотеки и используется только как евангелие в нем. Одним из наиболее частых отклонений PEP 8 для других фрагментов кода является именование переменных, особенно для методов. Нет единого преобладающего стиля, хотя, учитывая объем кода, который использует mixedCase, если кто-то должен был провести строгую перепись, вероятно, в конечном итоге окажется версия PEP 8 с mixedCase. Существует немного другого отклонения от PEP 8, что довольно распространено.
Как уже упоминалось, PEP 8 говорит использовать lower_case_with_underscores для переменных, методов и функций.
Я предпочитаю использовать lower_case_with_underscores для переменных и mixedCase для методов и функций, делая код более явным и читаемым. Таким образом, следуя Zen of Python, "явный лучше, чем неявный" и "Readability counts"
Лично я пытаюсь использовать CamelCase для классов, методов и функций mixedCase. Переменные обычно выделяются (если я помню). Таким образом, я могу сразу сказать, что именно я называю, а не все, что выглядит одинаково.
далее на что @JohnTESlade ответил. Руководство по стилю Google Python содержит несколько хороших рекомендаций,
Имена, которых следует избегать
\__double_leading_and_trailing_underscore__ names (зарезервировано Python)Соглашение об именах
CapWords для имен классов, но lower_with_under.py для имен модулей. Хотя существует много существующих модулей с именем CapWords.py, сейчас это не рекомендуется, потому что это сбивает с толку, когда модуль назван в честь класса. ("подождите, я написал import StringIO или from StringIO import StringIO?")Руководства, основанные на рекомендациях Гвидо
Большинство пользователей 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. Вот почему современные языки используют (или должны использовать) змею везде, где могут.
Стиль кодирования обычно является частью внутренних правил политики/конвенций организации, но я думаю, что в общем случае стиль all_lower_case_underscore_separator (также называемый snake_case) наиболее распространен в python.
Я лично использую соглашения об именах Java при разработке на других языках программирования, так как они последовательны и просты в использовании. Таким образом, я не буду постоянно спорить о том, какие соглашения использовать, которые не должны быть самой сложной частью моего проекта!
Как правило, следуйте соглашениям, используемым в стандартной библиотеке языков.