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: Function and Variable Names：
函数名称应为小写，必要时用下划线分隔单词以提高可读性。变量名遵循与函数名相同的约定。混合大小写只允许在已经是流行样式的上下文中（例如 threading.py），以保持向后兼容性。
Google Python Style Guide 具有以下约定：
模块名、包名、类名、方法名、异常名、函数名、GLOBAL_CONSTANT_NAME、全局变量名、实例变量名、函数参数名、本地变量名。
应将类似的命名方案应用于 CLASS_CONSTANT_NAME
property ...也许这是该项目假装的问题，而不是它实际上是什么
David Goodger（在“像 Pythonista 一样的代码”here 中）描述了 PEP 8 建议如下：
join_lower 用于函数、方法、属性、变量
join_lower 或 ALL_CAPS 用于常量
用于课堂的StudlyCaps
camelCase 仅符合预先存在的约定
joined_lower 的位置，但只有“所有带有下划线分隔单词的大写字母”。还对新的 enum 功能感到好奇。
StudlyCaps for classes 是一个适用于几乎所有语言的类的通用规则。那为什么有些python内置类（比如datetime.datetime）不遵循这个约定？
unittest.TestCase.assertEqual 和朋友们也没有遵循蛇案例约定。事实是，Python 标准库的某些部分是在约定固化之前开发的，而我们现在被它们困住了。
正如 Style Guide for Python Code 承认的那样，
Python 库的命名约定有点乱，所以我们永远不会完全一致
请注意，这仅指 Python 的标准库。如果他们不能保持一致，那么几乎没有希望为所有 Python 代码制定一个普遍遵守的约定，是吗？
从这点，以及这里的讨论，我会推断，如果一个人在过渡到 Python 时继续使用例如 Java 或 C#（明确和完善）的变量和函数命名约定，这并不是一种可怕的罪过。当然，请记住，最好遵守代码库/项目/团队的流行风格。正如 Python 风格指南所指出的，内部一致性最重要。
请随意将我视为异端。 :-) 像 OP 一样，我不是“Pythonista”，反正还不是。
如前所述，PEP 8 说将 lower_case_with_underscores 用于变量、方法和函数。
我更喜欢将 lower_case_with_underscores 用于变量，将 mixedCase 用于方法和函数，这样可以使代码更加明确和易读。因此遵循Zen of Python's“显式优于隐式”和“可读性计数”
正如其他答案所示，有 PEP 8，但 PEP 8 只是标准库的样式指南，在其中仅被视为福音。 PEP 8 对于其他代码段最常见的偏差之一是变量命名，特别是对于方法。没有单一的主要风格，尽管考虑到使用混合大小写的代码量，如果要进行严格的人口普查，最终可能会使用混合大小写的 PEP 8 版本。几乎没有其他与 PEP 8 一样常见的偏差。
进一步了解@JohnTESlade 的回答。 Google's python style guide 有一些非常简洁的建议，
要避免的名字
除计数器或迭代器外的单个字符名称
任何包/模块名称中的破折号 (-)
\__double_leading_and_trailing_underscore__ 名称（由 Python 保留）
命名约定
“内部”是指模块内部或类中受保护或私有的。
前置单个下划线 (_) 对保护模块变量和函数有一些支持（不包括在 import * from 中）。为实例变量或方法添加双下划线 (__) 可以有效地使变量或方法对其类私有（使用名称修饰）。
将相关的类和顶级函数放在一个模块中。与 Java 不同，没有必要将自己限制为每个模块一个类。
使用 CapWords 作为类名，而使用 lower_with_under.py 作为模块名。尽管有许多名为 CapWords.py 的现有模块，但现在不鼓励这样做，因为当模块碰巧以类命名时会造成混淆。 （“等等——我写的是 import StringIO 还是 from StringIO import StringIO？”）
https://i.stack.imgur.com/uBr10.png
大多数 python 人更喜欢下划线，但即使我使用 python 已经超过 5 年了，我仍然不喜欢它们。它们对我来说看起来很丑，但也许这就是我脑海中的全部 Java。
我只是更喜欢 CamelCase，因为它更适合类的命名方式，SomeClass.doSomething() 感觉比 SomeClass.do_something() 更合乎逻辑。如果你在 python 中的全局模块索引中查看，你会发现两者，这是因为它是来自各种来源的库的集合，随着时间的推移而增长，而不是像 Sun 这样具有严格编码规则的公司开发的东西.我想说的底线是：使用任何你喜欢的更好的东西，这只是个人品味的问题。
make_xpath_predicate、make_xpath_expr、make_html_header、make_html_footer
SomeClass.doSomething()（静态方法通常很少见）您通常调用 an_instance.do_something()
我个人尝试将 CamelCase 用于类、mixedCase 方法和函数。变量通常用下划线分隔（当我记得的时候）。这样我就可以一眼看出我在调用什么，而不是所有看起来都一样。
有一篇关于此的论文：http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
TL;DR 它说snake_case 比camelCase 更具可读性。这就是为什么现代语言尽可能使用（或应该使用）蛇的原因。
编码风格通常是组织内部政策/约定标准的一部分，但我认为总的来说，all_lower_case_underscore_separator 风格（也称为蛇形案例）在 python 中最常见。
在使用其他编程语言进行开发时，我个人使用 Java 的命名约定，因为它一致且易于遵循。这样我就不会一直在为使用哪些约定而苦苦挣扎，这不应该是我项目中最难的部分！
library_function(my_arg)) 进行调用。
列宁告诉...我也来自 Java/C# 世界。和 SQL 一样。仔细检查自己，试图在一切都是对象的列表字典中找到复杂结构的第一眼可理解的示例，例如列表。至于我 - camelCase 或其变体应该成为任何语言的标准。复杂句子应保留下划线。
是否在课堂上或不在课堂上：
变量和函数都是小写的，如下所示：
name = "John"
def display(name):
print("John")
如果它们是多个单词，则用下划线“_”分隔，如下所示：
first_name = "John"
def display_first_name(first_name):
print(first_name)
并且，如果变量是常量，则为大写，如下所示：
FIRST_NAME = "John"
通常，遵循语言标准库中使用的约定。
findMeAClass可能比find_me_a_class更丑。