如何使用缩写词命名变量?
例如,在 Java 中,我将数据传输对象用作:
ExampleDTO exampleDTO = new ExampleDTO();
那么,如果我遵循 PEP 8 (lower_case_with_underscores),我应该在 Python 中使用什么命名约定?
For example in Java for Data Transfer Object I use as:
ExampleDTO exampleDTO = new ExampleDTO();
So, if I am following PEP 8 (lower_case_with_underscores), what naming convention should I use for similar in Python?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
最符合 PEP-8 的风格可能是...
example_dto = ExampleDTO()
The style most agreeing with PEP-8 would probably be...
example_dto = ExampleDTO()
你可能想看看 Python 风格指南
我个人使用驼峰命名法作为变量和 _(下划线)在方法名称中分隔。
You may want to look at Python Style Guide
I personally use camelCase for variables and _ (underscore) separated in method names.
为什么首先使用缩写词?我会尽可能避免它们。他们混淆代码并倾向于创建难以浏览和快速阅读的代码。最坏的情况是,它们会因为误解而带来错误(RndCmp 是随机比较而不是舍入复数)。
什么是 DTO? 2年后还能用吗?每个新人都会立即知道这意味着什么吗? 5年后也是如此吗?它会与其他东西混淆吗? (确定性和可转移对象?)
使用首字母缩略词的唯一真实(且诚实)的原因是纯粹的编码员懒惰。我在会议中的乐趣在于询问变量名称中的缩写词,但 80% 的情况下没有人真正知道。即使是老家伙也忘记了几年前这意味着什么。我们甚至有一些具有不止一种含义。
如今有了自动完成变量名称的优秀 IDE (??),懒惰是保留它们的一个非常糟糕的理由。根据经验,你无法阻止它们,但应该始终对它们提出质疑。
Why use acronyms in the first place? I try to avoid them when possible. They obfuscate the code and tend to create code that is hard to browse for quick read. Worst case they bring bugs because of misinterpretation (RndCmp was a Random Compare not a Rounded Complex).
What is DTO? Will it still be used in 2 years? Will every new guy immediately know what it means? In 5 years from now too? Can it be confused with anything else? (Deterministic and Transferable Object?)
The only true (and honest) reason for using acronyms is pure coder laziness. My fun in meetings is to ask about acronyms in variable names and 80% of the times nobody really knows. Even the old guys forget what it meant a couple of years back. We even have some with more than one meanings.
With today great IDE (??) with auto-complete of variable names, laziness is a very bad reason to keep them around. By experience you cannot prevent them, but they should always be questioned.