我是一名 java 程序员,但现在进入“python 领域”,以了解 Python 更适用的一些东西。我很确定我的大部分代码对于 Python 程序员来说看起来很奇怪(例如,在每个 if 上都使用括号)。
我知道每种语言都有自己的约定和一套“习惯”。那么,从可读性的角度来看,什么是 Java 中“要走的路”的约定和实践,但不是真正的“pythonic 方式”?
我是一名 java 程序员,但现在进入“python 领域”,以了解 Python 更适用的一些东西。我很确定我的大部分代码对于 Python 程序员来说看起来很奇怪(例如,在每个 if 上都使用括号)。
我知道每种语言都有自己的约定和一套“习惯”。那么,从可读性的角度来看,什么是 Java 中“要走的路”的约定和实践,但不是真正的“pythonic 方式”?
这个问题没有简单的答案。您的代码需要时间才能成为"Pythonic"。不要尝试在 Python 中重新创建 Java 习语。学习 Python 习语只需要时间。
看看像 Pythonista 一样的代码:Idiomatic Python、Python Code Style Guide和Python for Java Programmers(已归档)。
Jacob Hallén 曾观察到最好的 Python 风格遵循Tufte拒绝装饰(尽管 Tufte 的领域不是编程语言,而是信息的视觉显示):不要浪费“墨水”(像素)或“纸张”(空间)仅仅是装饰。
很多东西都遵循这个原则:没有多余的括号,没有分号,注释和文档字符串中没有愚蠢的“ascii 框”,没有浪费空间来“对齐”不同行上的东西,单引号,除非你特别需要双引号,没有 \ 继续行,除非是强制性的,没有评论只是提醒读者语言规则(如果读者不知道你遇到麻烦的语言;-)等等。
我应该指出,在 Python 社区中,“Python 的 Tufte 精神”的一些后果比其他后果更具争议性。但这种语言确实非常尊重“塔夫特的精神”......
转向“更具争议性”(但受到 Python 之禅的认可——import this
在解释器提示下):“扁平比嵌套更好”,所以“尽快退出”而不是嵌套。让我解释:
if foo:
return bar
else:
baz = fie(fum)
return baz + blab
这并不可怕,但也不是最优的:因为“return”“出去”,你可以保存嵌套:
if foo:
return bar
baz = fie(fum)
return baz + blab
一个更尖锐的例子:
for item in container:
if interesting(item):
dothis(item)
dothat(item)
theother(item)
双层嵌套的大块并不整洁......考虑更扁平的风格:
for item in container:
if not interesting(item):
continue
dothis(item)
dothat(item)
theother(item)
顺便说一句,还有一个不是专门针对 Python 专有风格的旁白——我最讨厌的一个(在任何语言中,但在 Python 中,Tufte 的精神支持我;-):
if not something:
this()
that()
theother()
else:
blih()
bluh()
blah()
“如果不是……否则”是扭曲的!交换两半并失去not
:
if something:
blih()
bluh()
blah()
else:
this()
that()
theother()
最好的起点可能是PEP-8,它是官方 Python 风格指南。它涵盖了许多被认为是标准的基础知识。
另外,之前的一些stackoverflow问题:
“一切都是一个类”是一个 Java 习语,它特别不是 Python 习语。(几乎)一切都可以是 Python 中的一个类,如果这对你来说更舒服,那就去吧,但 Python 不需要这样的东西。Python 不是一种纯粹的面向对象的语言,在我(有限的)经验中,将这一点铭记于心是件好事。
语法只是冰山一角。Java 程序员应该注意许多不同的语言结构,例如 Python 不需要使用接口
在 python 中创建接口和可交换实现_python_帮酷编程问答
另一个真正有用的习语是一切都可以转换为 Python 中具有直观含义的布尔值。例如,要检查一个空数组,您只需执行
if not my_array:
return
...process my_array...
第一个条件相当于 Java 的
if ((my_array == null) || (my_array.length == 0)) {
return
}
这是 Python 中的天赐之物。它不仅更简洁,而且还避免了许多人不会始终检查这两个条件的 Java 陷阱。结果避免了无数 NullPointerException。