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

300   12  

12 ответов:

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

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

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

переменные...

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

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

Google Python Style Guide имеет следующее соглашение:

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"здесь) описывает рекомендации ОПТОСОЗ 8 следующим образом:

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

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

  • StudlyCaps для занятия

  • camelCase только для того чтобы соответствовать ранее существовавшие соглашения

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

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

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

из этого и обсуждения здесь я бы сделал вывод, что это не ужасный грех, если вы продолжаете использовать, например, 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. руководство по стилю python от Google имеет некоторые довольно интересные рекомендации,

имена, чтобы избежать

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

Соглашение Об Именах

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

рекомендации, полученные из рекомендаций Гвидо enter image description here

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

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

    Ничего не найдено.

Добавить ответ:
Отменить.