Python 表示法?

发布于 2024-07-27 16:56:43 字数 493 浏览 7 评论 0原文

我刚刚开始使用 Python,我正在考虑应该使用哪种表示法。 我已阅读关于 Python 表示法的 PEP 8 指南,我同意除了函数名称(我更喜欢混合大小写风格)之外的大多数内容。

在 C++ 中,我使用匈牙利表示法的修改版本,其中不包含有关类型的信息,而仅包含有关变量范围的信息(例如,lVariable 表示局部变量,mVariable 表示类的成员变量,g 表示全局变量, s 代表静态,in 代表函数的输入,out 代表函数的输出。)

我不知道这种表示法样式是否有名称,但我想知道在 Python 中不使用这种表示法样式是否是一个好主意。 我对 Python 不是很熟悉,所以你们可能会看到我无法想象的问题。

我也有兴趣了解您对它的总体看法:)有些人可能会说这使代码的可读性较差,但我已经习惯了,没有这些标签编写的代码对我来说可读性较差。

I've just started using Python and I was thinking about which notation I should use. I've read the PEP 8 guide about notation for Python and I agree with most stuff there except function names (which I prefer in mixedCase style).

In C++ I use a modified version of the Hungarian notation where I don't include information about type but only about the scope of a variable (for instance lVariable for a local variable and mVariable for a member variable of a class, g for global, s for static, in for a function's input and out for a function's output.)

I don't know if this notation style has a name but I was wondering whether it's a good idea not to use such a notation style in Python. I am not extremely familiar with Python so you guys/gals might see issues that I can't imagine yet.

I'm also interested to see what you think of it in general :) Some people might say it makes the code less readable, but I've become used to it and code written without these labels is the code that is less readable for me.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

姐不稀罕 2024-08-03 16:56:43

几乎每个Python程序员都会说它使代码可读性较差,但我已经习惯了,没有这些标签编写的代码对我来说可读性较差)

FTFY。

但说真的,它会对你有所帮助,但会让其他试图阅读你的代码的 Python 程序员感到困惑和烦恼。

由于 Python 本身的工作原理,这也不是必需的。 例如,您永远不需要“mVariable”形式,因为它在Python中很明显:

class Example(object):
    def__init__(self):
        self.my_member_var = "Hello"

    def sample(self):
        print self.my_member_var

e = Example()
e.sample()
print e.my_member_var

无论您如何访问成员变量(使用self.foomyinstance. foo) 总是很清楚它是一个成员。

其他情况可能不是那么明显,但是如果您的代码不够简单,读者在读取函数时可以记住“'names'变量是一个参数”,那么您可能做错了什么。

(Almost every Python programmer will say it makes the code less readable, but I've become used to it and code written without these labels is the code that is less readable for me)

FTFY.

Seriously though, it will help you but confuse and annoy other Python programmers that try to read your code.

This also isn't as necessary because of how Python itself works. For example you would never need your "mVariable" form because it's obvious in Python:

class Example(object):
    def__init__(self):
        self.my_member_var = "Hello"

    def sample(self):
        print self.my_member_var

e = Example()
e.sample()
print e.my_member_var

No matter how you access a member variable (using self.foo or myinstance.foo) it's always clear that it's a member.

The other cases might not be so painfully obvious, but if your code isn't simple enough that a reader can keep in mind "the 'names' variable is a parameter" while reading a function you're probably doing something wrong.

无所的.畏惧 2024-08-03 16:56:43

使用 PEP-8。 它在 Python 世界中几乎是通用的。

Use PEP-8. It is almost universal in the Python world.

决绝 2024-08-03 16:56:43

我的代码违反了 PEP8。 我使用:

  • lowercaseCamelCase 表示方法和函数
  • _prefixedWithUnderscoreLowercaseCamelCase 表示“私有”方法
  • underscore_spaced 表示变量(任何)
  • _prefixed_with_underscore_variables 表示“私有”自变量(属性)
  • CapitalizedCamelCase 表示类和模块(尽管我正在转向小写模块)

我从来不喜欢匈牙利表示法。 变量名应该简单明了,提供足够的信息以明确它在哪里(在哪个范围)使用以及它的目的是什么,易于阅读,关注它所指代的含义,而不是其技术性的胡言乱语(例如类型)。

我的违规行为背后的原因是出于实际考虑和以前的经验。

  • 在 C++ 和 Java 中,传统上使用 CapitalizedCamel 表示类,使用 lowercaseCamel 表示成员函数。
  • 我在一个代码库上工作,其中下划线前缀用于表示私有但不是那么私有。 我们不想弄乱 python 名称修改(双下划线)。 这使我们有机会在单元测试期间违反一些形式并窥视内部类状态。

I violate PEP8 in my code. I use:

  • lowercaseCamelCase for methods and functions
  • _prefixedWithUnderscoreLowercaseCamelCase for "private" methods
  • underscore_spaced for variables (any)
  • _prefixed_with_underscore_variables for "private" self variables (attributes)
  • CapitalizedCamelCase for classes and modules (although I am moving to lowercasedmodules)

I never liked hungarian notation. A variable name should be easy and concise, provide sufficient information to be clear where (in which scope) it's used and what is its purpose, easy to read, concerned about the meaning of what it refers to, not its technical mumbo-jumbo (eg. type).

The reason behind my violations are due to practical considerations, and previous experience.

  • in C++ and Java, it's tradition to have CapitalizedCamel for classes and lowercaseCamel for member functions.
  • I worked on a codebase where the underscore prefix was used to indicate private but not that much private. We did not want to mess with the python name mangling (double underscore). This gave us the chance to violate a bit the formalities and peek the internal class state during unit testing.
时光清浅 2024-08-03 16:56:43

有一个方便的 pep-8 合规性脚本,您可以针对您的代码运行:

http:// github.com/cburroughs/pep8.py/tree/master

There exists a handy pep-8 compliance script you can run against your code:

http://github.com/cburroughs/pep8.py/tree/master

空心空情空意 2024-08-03 16:56:43

这将取决于项目和目标受众。

如果您正在构建开源应用程序/插件/库,请遵循 PEP 指南。

如果这是您公司的项目,请遵守公司惯例或类似的规定。

如果这是您自己的个人项目,那么请使用流畅且易于使用的约定。

我希望这是有道理的。

It'll depend on the project and the target audience.

If you're building an open source application/plug-in/library, stick with the PEP guidelines.

If this is a project for your company, stick with the company conventions, or something similar.

If this is your own personal project, then use what ever convention is fluid and easy for you to use.

I hope this makes sense.

一刻暧昧 2024-08-03 16:56:43

您应该简单地与自己的代码中的命名约定保持一致。 但是,如果您打算将代码发布给其他开发人员,您应该坚持使用 PEP-8。

例如,当您有一个协作项目时,4 个空格与 1 个选项卡是一个大问题。 人们使用选项卡向源存储库提交代码需要开发人员不断争论空格问题(这在 Python 中是一件大事)。

Python 和所有语言都有首选约定。 你应该学习它们。

Java 喜欢混合大小写。

C 喜欢 szHungarianNotation。

Python 更喜欢 stuff_with_underscores。

您可以使用_python_type_function_names编写Java代码。
您可以使用 javaStyleMixedCaseFunctionNamesThatAreSupposedToBeReallyExplict 编写 Python 代码,

只要您一致 :p

You should simply be consistent with your naming conventions in your own code. However, if you intend to release your code to other developers you should stick to PEP-8.

For example the 4 spaces vs. 1 tab is a big deal when you have a collaborative project. People submitting code to a source repository with tabs requires developers to be constantly arguing over whitespace issues (which in Python is a BIG deal).

Python and all languages have preferred conventions. You should learn them.

Java likes mixedCaseStuff.

C likes szHungarianNotation.

Python prefers stuff_with_underscores.

You can write Java code with_python_type_function_names.
You can write Python code with javaStyleMixedCaseFunctionNamesThatAreSupposedToBeReallyExplict

as long as your consistant :p

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文