Яка умова іменування в 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?

Див. Python PEP 8: Імена функцій та змінних :

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

Імена змінних дотримуються тієї ж умови, що і назви функцій.

Змішана дозволена лише в контекстах, де це вже переважаючий стиль (наприклад, threading.py ), щоб зберегти зворотну сумісність.

Керівництво Стиль 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

Девід Goodger (в «Code Подібно Pythonista» тут ) описує PEP 8 рекомендацій наступним чином :

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

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

• StudlyCaps для занять

• camelCase лише відповідно до попередніх конвенцій

Як визнає посібник зі стилів для Python Code ,

Конвенції про іменування бібліотеки Python трохи заплутані, тому ми ніколи не будемо цілком узгоджувати це

Зауважте, що це стосується лише стандартної бібліотеки Python . Якщо вони не можуть досягти такої послідовності, то навряд чи є велика надія на загальне дотримання конвенції для всіх кодів Python?

З цього і обговорення тут, я б зробив висновок, що це не жахливий гріх, якщо можна продовжувати використовувати, наприклад, Java або C # 's (чіткі і чітко встановлені) умови іменування змінних та функцій при переході на Python. Звичайно, маючи на увазі, що найкраще дотримуватися того стилю, який склався для кодової бази / проекту / команди. Як вказує керівництво по стилю Python, внутрішня узгодженість найбільше значення має .

^{Сміливо звільняйте мене як єретика. :-) Як і ОП, я все ще не "пітоніст".}

Існує PEP 8 , як показують інші відповіді, але PEP 8 є лише стилістичним довідником для стандартної бібліотеки, і це тільки приймається Євангеліє в ньому. Одне з найчастіших відхилень PEP 8 для інших фрагментів коду - це називання змінної, спеціально для методів. Не існує єдиного стилю переважаючого, хоча враховуючи об'єм коду, який використовує змішануCase, якби проводити суворий перепис, мабуть, вийде версія PEP 8 зі змішанимCase. Інших відхилень від PEP 8 мало, що досить часто.

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

Я вважаю за краще використовувати lower_case_with_underscoresдля змінних, а також mixedCaseдля методів і функцій, робить код більш явним і читабельним. Таким чином, слідування дзену Python "явне краще, ніж неявне" і "Читання рахунків"

далі на те, що відповів @JohnTESlade. Посібник зі стилю python від Google має кілька акуратних рекомендацій,

Імена, яких слід уникати

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

Конвенція про іменування

• "Внутрішній" означає внутрішній модуль або захищений або приватний в межах класу.
• Попередження єдиного підкреслення (_) має деяку підтримку захисту змінних модулів та функцій (не входить до імпорту * з). Попередження подвійного підкреслення (__) до змінної екземпляра або методу ефективно служить для того, щоб змінна чи метод були приватними для свого класу (використовуючи керування іменами).
• Розміщуйте пов’язані класи та функції вищого рівня разом у модулі. На відміну від Java, немає необхідності обмежувати себе одним класом на модуль.
• Використовувати CapWordsдля назв класів, але lower_with_under.pyдля назв модулів. Хоча існує чимало існуючих модулів з назвою CapWords.py, це зараз відлякує, оскільки це заплутано, коли модуль буде іменований назви класу. ("зачекайте - я написав import StringIOчи from StringIO import StringIO?")

Настанови, що випливають з Рекомендацій Гуйдо

Більшість людей-пітонів вважають за краще підкреслювати, але навіть якщо я вже більше 5 років використовую python, я все ще не люблю їх. Вони просто негарно виглядають на мені, але, можливо, це все Ява в моїй голові.

Я просто як CamelCase краще , так як він краще підходить тим , як класи по імені, він відчуває себе більш логічно мати SomeClass.doSomething()чим SomeClass.do_something(). Якщо озирнутися в глобальному індексі модуля в python, ви знайдете і те, і інше, що пов'язано з тим, що це колекція бібліотек з різних джерел, які зростали понаднормово, а не те, що було розроблено однією компанією, як Sun, із суворими правилами кодування . Я б сказав, що підсумок: Використовуйте все, що вам більше подобається, це лише питання особистого смаку.

Особисто я намагаюся використовувати CamelCase для класів, методів та функцій змішаного казу. Змінні зазвичай підкреслюються підкресленням (коли я можу згадати). Таким чином я можу з першого погляду сказати, що саме я дзвоню, а не все, що виглядає однаково.

Про це є стаття: http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR Це говорить про те, що snake_case легше читати, ніж camelCase. Ось чому сучасні мови використовують (або повинні вживати) змію, де тільки можуть.

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

Я особисто використовую конвенції про іменування Java під час розробки інших мов програмування, оскільки це послідовно і легко дотримуватися. Таким чином, я не безперервно борюся за те, які конвенції використовувати, які не повинні бути найважчою частиною мого проекту!

Як правило, слід дотримуватися умов, які використовуються в стандартній бібліотеці мови.