当前位置:  开发笔记 > 编程语言 > 正文

Python中变量和函数名称的命名约定是什么?

如何解决《Python中变量和函数名称的命名约定是什么?》经验,为你挑选了10个好方法。

来自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有更优选的,明确的编码风格吗?



1> S.Lott..:

请参阅Python PEP 8.

函数名称应为小写,并根据需要用下划线分隔,以提高可读性.

只有在已经成为流行风格的情境中才允许使用mixedCase

变量...

使用函数命名规则:小写,必要时用下划线分隔,以提高可读性.

就个人而言,我与此不同,因为我也喜欢mixedCaselower_case我自己的项目.


我确实遵循惯例,但我真的很讨厌每种语言都必须为一切发明略微不同的约定.函数/方法的示例 - AbsolutelyStupid(C#),absoluteStupid(Java),absolutely_stupid(Python),Absolutely_Stupid(我不记得了)和absost(C++ std::),
PEP = Python增强建议.
mixedCase非常易读且赏心悦目.我很好,Python缺少括号但没有缺席;也许我会.但是lower_case只是简单的丑陋.示例:>>>> thisIsMixedCaseVariable和>>>> this_is_lower_case_underscore_filled_variable现在正如他们所说的那样,对每个人都有自己的品味.
强调风格的一个案例是你可以更好地使用单字母单词.对于(一个相当愚蠢的)例子,`findMeAClass`可能比`find_me_a_class`更丑陋.
我发现的一件事是,如果你是一个相当快的打字员,lower_function_names的输入要比lowerFunctionNames慢50%对我来说
@rr PEP8是一个"风格指南",并将自己描述为一个公约,而不是一个标准.它也清楚地解释了不总是遵循这些"规则"的原因.
@RickyRobinson你使用的是什么脑死代码编辑器,不知道下划线会继续说一个字?有很多免费的.如果IDE不可用,我使用Notepad ++.为此,可以下载用于python编辑的模板.(其他人可以推荐更有用的免费下载.)
我发现全小写变量名的约定不适用于科学计算,其中经常遇到用大写字母表示的众所周知的常量,张量等.
使用下划线的唯一问题是您无法通过双击选择变量或函数名称...您必须手动选择文本.这有点烦人.
我把一个sed命令转换成了reduceCase(但不是CapitalWords)转换为lower_case_with_underscores,以防有人发现它有用,例如以你喜欢的方式做,但然后以PEP 8首选方式发布它:http://stackoverflow.com/问题/ 23607374
函数参数名称(特别是关键字参数)怎么样?PEP 8并未明确指出它们.我假设它们也是带有下划线的小写字母.或者是小写_without_下划线首选?

2> JohnTESlade..:

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

类似的命名方案应该应用于a CLASS_CONSTANT_NAME


a)我喜欢这些例子 - 谢谢.b)CamelCase和下划线没有吸引力的混合物?但是:对于Python及其更灵活的数据模型不熟悉,我敢打赌Google的指南背后有坚实的想法......
@MatthewCornell混合也不错,只要你坚持下去.如果你知道函数有下划线而类没有,那么它实际上使可读性更容易.
和CLASS_CONSTANT_NAME
我唯一要改变的是函数名称(functionName)的驼峰案例 - 它可以帮助很多读取dir(模块)来区分可调用和变量.

3> unmounted..:

大卫·Goodger(在"代码就像Pythonista" 在这里)描述了PEP 8项建议如下:

joined_lower 用于函数,方法,属性,变量

joined_lower或者ALL_CAPS常数

StudlyCaps 对于课程

camelCase 只是为了符合已有的惯例


+1视觉示例.虽然我看不出PEP8在**常数**中建议`joined_lower`的位置,但只有"所有带有下划线的大写字母分隔单词".好奇的还有关于[enum](http://stackoverflow.com/a/1695250/673991)的新功能.
@PrahladYeri:不幸的是,`unittest.TestCase.assertEqual`和朋友也不遵循snake_case约定.事实上,Python标准库的某些部分是在约定固化之前开发的,现在我们已经坚持使用它们了.
CamelCase令人困惑,因为有人说它是"camelCase"(也称为"mixedCase"),有人说它是"CamelCase"(也称为"StudlyCaps").例如,当你提到"camelCase"时,PEP会提到"CamelCase".

4> Jonik..:

正如Python Code的样式指南所承认的那样,

Python库的命名约定有点混乱,所以我们永远不会完全一致

请注意,这仅指Python的标准库.如果他们不能得到那种一致性,那么几乎没有希望对所有 Python代码都有一个普遍遵守的约定,是吗?

从那里开始,在这里讨论,我会推断,如果在跨越Python时继续使用例如Java或C#(明确且完善的)变量和函数的命名约定,这不是一个可怕的罪.当然,请记住,最好遵守代码库/项目/团队的主流风格.正如Python样式指南所指出的那样,内部一致性最重要.

随意将我视为异教徒.:-)和OP一样,我不是"Pythonista",不管怎样.



5> Thomas Woute..:

正如其他答案所示,有PEP 8,但PEP 8只是标准库的样式指南,并且它仅作为福音.PEP 8对其他代码的最常见偏差之一是变量命名,特别是对于方法.没有单一的主导风格,虽然考虑到使用mixedCase的代码量,如果要进行严格的人口普查,最终可能会得到一个带有mixedCase的PEP 8版本.PEP 8几乎没有其他偏差,这很常见.


这可能是在08年得到回应的时候,但现在几乎所有的主要图书馆都使用PEP 8命名惯例.

6> claytron..:

如上所述,PEP 8表示lower_case_with_underscores用于变量,方法和功能.

我更喜欢使用lower_case_with_underscores变量,mixedCase方法和函数使代码更加明确和可读.因此遵循Python的禅宗 "明确比隐含更好"和"可读性计数"


+1我切换那两个(我使用mixedCase作为变量),但是让所有内容更加清晰,这有助于让你立即明白你所处理的内容,特别是因为你可以传递函数.
虽然“可读性”是高度主观的。我发现下划线的方法更具可读性。

7> Sufiyan Ghor..:

进一步了解@JohnTESlade所回答的问题.谷歌的python风格指南有一些非常好的建议,

要避免的名称

除计数器或迭代器之外的单个字符名称

任何包/模块名称中的破折号( - )

\__double_leading_and_trailing_underscore__ names (由Python保留)

命名惯例

"内部"表示模块内部或类中受保护或私有.

预先设置单个下划线(_)对保护模块变量和函数(不包含在import*中)有一些支持.将双下划线(__)预先添加到实例变量或方法有效地使变量或方法对其类是私有的(使用名称修改).

将相关类和顶级函数放在一个模块中.与Java不同,不需要将每个模块限制为一个类.

使用CapWords类的名字,但lower_with_under.py对模块名称.尽管有许多现有的模块被命名CapWords.py,但现在不鼓励这样做,因为当模块恰好以类命名时,它会让人感到困惑.("等等 - 我写了import StringIO还是from StringIO import StringIO?")

来自Guido建议书的指南 在此输入图像描述



8> crystalattic..:

我个人尝试将CamelCase用于类,mixedCase方法和函数.变量通常是下划线(当我记得时).通过这种方式,我可以一目了然地告诉我究竟是在呼唤什么,而不是一切看起来都一样.


Camel案例以小写字母IIRC开头,如"camelCase".
我认为crystalattice是正确的 - 至少,他的用法与PEP8(CamelCase和mixedCase)中的用法一致.

9> André..:

大多数python人喜欢下划线,但即使我使用python已经超过5年了,我仍然不喜欢它们.他们看起来很难看,但也许这就是我头脑中的Java.

我只是喜欢驼峰更好,因为它适合与类的命名方式更好,感觉更符合逻辑具有SomeClass.doSomething()SomeClass.do_something().如果你在python中查看全局模块索引,你会发现两者,这是因为它是来自各种来源的库的集合,这些库随着时间的推移而增长,而不是像Sun这样的公司用严格的编码规则开发的东西. .我会说底线是:使用你喜欢的任何东西,这只是个人品味的问题.


我来自Java背景,我发现下划线冗长而且没有吸引力,只有后者是意见.命名在某些方面是可读性和简洁性之间的平衡.Unix太过分了,但它的http://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()`。

10> alebian..:

有一篇关于此的论文:http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf

TL; DR它说snake_case比camelCase更具可读性.这就是现代语言在任何可能的地方使用(或应该使用)蛇的原因.


有趣的是,它还说,"这项研究的结果可能不一定适用于嵌入在源代码中的标识符.当嵌入到编程结构中时,完全有可能将骆驼标识符作为更好的格式元素."
推荐阅读
kikokikolove
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有